Download the PDF 

Configuring Policy via Radius Authentication

Introduction

Document Number

ENG-010428 

Purpose

The purpose of this document is to define how to set up the system to use NAC in conjunction with Radius Authentication and 802.1x to define the services or "policy" on a user port.  This allows the configuration of the port to be based on which user logs into the port.  This is known as dynamic services where the policy is dynamic, based on user login, and populated by Radius.

This document will explain the concepts involved; define how to configure the Tellabs system, and how to troubleshoot the implementation. 

Applies To

This application note applies to all Tellabs 1150, and 1134/OLT6 systems and associated ONTs. 

Definitions 

• NAC – Network Access Control, in Tellabs system, a dynamic method of assigning services or policy to a port.  This can be statically or dynamically assigned based on configuration.
• 802.1x – Port based Network Access control, which is defined by the IEEE 802.1 standard.  This protocol denies access to an Ethernet port until the supplicant has successfully authenticated.
• RADIUS – Remote Authentication Dial In User Service is a protocol that provides centralized Authentication, Authorization, and Accounting management of users.  RADIUS can also be based on user authentication, send back a set of TLVs (Tag Length Value) that define VLAN, Policy, and many other pieces of information.

How Do 802.1x and Radius Work?

802.1X authentication involves three parties: a supplicant, an authenticator, and an authentication server. The supplicant is a client device (such as a laptop) that wishes to attach to the LAN/WLAN – though the term 'supplicant' is also used interchangeably to refer to the software running on the client that provides credentials to the authenticator. The authenticator is a network device, such as an Ethernet switch or wireless access point; and the authentication server is typically a host running software supporting the RADIUS and EAP protocols.

The authenticator acts like a security guard to a protected network. The supplicant (i.e., client device) is not allowed access through the authenticator to the protected side of the network until the supplicant’s identity has been validated and authorized. An analogy to this is providing a valid visa at the airport's arrival immigration before being allowed to enter the country. With 802.1X port-based authentication, the supplicant provides credentials, such as username/password or digital certificate, to the authenticator, and the authenticator forwards the credentials to the authentication server for verification. If the authentication server determines the credentials are valid, the supplicant (client device) is allowed to access resources located on the protected side of the network.

In addition to authenticating the user, RADIUS can supply various TLVs that are acted on by the Authenticator.  It can pass back a Filter-Id which typically defines policy for the port.  It can also return identification of the port in the form of an IFALIAS.  The RADIUS server can also define the VLAN(s) in use on the port.

Using Service Profile-Match for Generic Policies

The Tellabs OLAN system supports a vendor-specific extension of the Filter-ID field to allow a more generic method for configuring the system.  This Filter-ID extension causes the system to do a search of the profiles assigned to a port and look for a prefix match.  The system will then assign the profile to the Ethernet port.    

You can then use local policies when you assign profiles to ports within a facility or geographic region.  The actual policies within your policy engine (ISE, Clearpass, Forescout, etc.) can then be generic and would rarely need to be changed, even when adding new facilities.  

 You might have for each floor of a building, one for data, and one for phones.  These VLANs are specific to a geographic location, but logically there is a phone and data VLAN per floor.  In the EMS, all ports on the first floor would be assigned with a NAC profile with all VLANs used on that floor.

Tellabs Filter ID Syntax

PROFILE-MATCH Syntax

When using profile match, the syntax is as follows: 

          TLAB:PROFILE-MATCH=<Service Profile Name Prefix>

Where <Service Profile Name Prefix> is the substring you want to match at the beginning of the profile name.  Then the service profiles would all be named based on their logical function rather than the specific profile for that port.  (ex. CAMERA, DATA, GUEST, PRINTER, SECURITY, VIDEO, VOICE).

As an example, ports on floor 1 might have service profile DATA-FLOOR-1 assigned to them, while ports on floor 2 might have DATA-FLOOR-2 assigned using the appropriate VLAN for that floor.  

The policy engine would simply send TLAB:PROFILE-MATCH=DATA and it would match the DATA-FLOOR-1 for ports on Floor 1 and DATA-FLOOR-2 for ports on Floor 2.  This allows the policy engine to profile the device and then use generic policies that are not aware of the specifics of a particular area.

PROFILE-ACL Syntax

The profile ACL syntax is used to assign an ACL profile to the port to identify the port to allow filtering of traffic on the port.

           TLAB:PROFILE-ACL=<acl profile name>

IFALIAS Syntax

The IFALIAS syntax is used to assign a USERLABEL to the port to identify the port.  This will be displayed on the EMS whenever a dynamic assignment has been made to the port and is a convenient way to use the NAC appliance profiling to identify the type of device on the port.  This will also appear at the SNMP interface to identify the port.

       TLAB:IFALIAS=<ifalias name> 

Typical Configuration Steps

This section will outline the high-level steps in a NAC setup: 

• Provision VLANs for services to be used – VLAN Properties and VLAN Assignments with Descriptions
• Enable Global 802.1x port-based access control – RADIUS Server Hostname / IP Address and Dynamic Authorization Client Hostname / IP Address
• Provision Profiles – ACL Profiles, Service Profiles, NAC Profiles, Ethernet Port Profiles, PoE Profiles, Ethernet Port RSTP Profiles, Ethernet Port PAE Profiles, and Ethernet Port LLDP Profiles
• Assign Profiles and Admin State to Ports 

NAC or network access control can be used to assign the policy or services to a port.  NAC is controlled by the NAC Profile which is assigned to Ethernet ports. 

NAC can either assign services to a port statically (via a static profile assigned to the port), or it can be dynamically assigned via Radius based on a user’s login credentials.  This Application Note will address services that are dynamically assigned via Radius.  It will also define how to properly configure a system to use Radius to assign services.

Provision VLANs to Be Used

The first step is to configure all the VLANs to be used by the system into the OLT using the Switching View of the Panorama EMS.  The VLANs need to be added to the VLAN Properties and then assigned to an Uplink Interface using the VLAN Assignment Tab.

• Using the VLAN Properties Tab, select the Create button and create an entry for each VLAN the user intends to use.  
• VLAN ranges should not be utilized when using external Policy Engines and all VLANs should be named.
• Typically, the policy engines will be enabling access to the VLAN and so the default policy for all VLANs should typically be Basic ACL Default Deny.
• The registration type should be dynamic, and it is always good practice to name the VLAN in the description field.
  
  
• Next, assign the VLANs to specific uplink interfaces or LAGs via the VLAN Assignment Tab.

Enable 802.1x Authorization

The next step is to configure the system to enable 802.1x Authentication.  The system will not do any 802.1x unless this is configured.  The 802.1x Port Authentication settings are reached by right-clicking on the OLT within the common tree, then selecting the menu item Protocols->Port Authentication.

The user should click the checkbox "Enable 802.1x Port Based Access Control".

It is also a good idea to set up the Radius server IP address(es) and Shared Key.  This defines the values for the Radius Profile named "default".   

OLT->Right click->Protocol->Port Authentication

The Port Authentication configuration menu will be displayed.

The RADIUS server can be specified as a hostname, but if a hostname is used, the OLT must be configured with the DNS server information and default domain. To configure the DNS settings for the OLT, use the right-click menu on the OLT in the common tree view and select Properties->General Tab.

Then Enable DNS, set the DNS Server IP and the default domain.

• Enable 802.1x port-based authentication – This enables the 802.1x/MAB service for the entire system.
• RADIUS Server Hostname / IP Address – This defines one or more radius servers that will service authentication.  For Policy Engines that include a radius server, this may be the IP of the engine.  The system will try each IP/Hostname in order and the first one to respond will be used for authentication.
• Shared Key – Defines the pre-shared key, or shared secret used to protect the interface with the RADIUS server.
• DAC Hostname / IP – Defines the Dynamic Authorization Client hostname or IP address which is used to provide many of the RADIUS extensions used by policy engines in configuration.  Typically, this is the Policy Engine address (ISE/Clearpass/Forescout, etc).  It is best practice to ensure that the Radius Hostname and DAC hostname are listed in the same order as in most systems. The RADIUS and DAC are fulfilled by the same agent.  Therefore, ordering them in the same order ensures that both parts of an authentication go to the same agent.
• DAC UDP Port – This is typically set to the standard default of 3799.

Set DNS Settings

If hostnames are used by the RADIUS or DAC agents, then you will need to configure the DNS entry on the OLT to allow the OLT to resolve the hostnames to IP addresses. 

The DNS entry can be reached by the right click menu of the OLT and selecting the General tab.

     OLT->Right click->General

• Enable DNS – Select enable DNS to enable the DNS service.
• DNS Servers – Add one or more DNS servers; up to 4 are supported.
• Default Domain – If desired, set the default domain.  

Provision Profiles to Be Used

 The following default naming conventions are recommended for the names to be used in the profile match use case.

Recommended Filter-ID PROFILE-MATCH and PROFILE-ACL names

NAC Profile: 

Default VLAN Service Profile Names – Filter-ID=TLAB:PROFILE-MATCH=

• CAMERA-Vx
• DATA-Vx
• GUEST-Vx
• PRINTER-Vx
• REMEDIATION-Vx
• SECURITY-Vx
• VIDEO-Vx
• VOICE-Vx

ACL Names – Filter-ID=TLAB:PROFILE-ACL=

• DEFAULT
• PERMIT-ALL-TRAFFIC
• NON-COMPLIANT
• CPP-REDIRECT
• CWA-REDIRECT 

Default ACL Profile

Typically, prior to a service being authorized on the port, the default profile is assigned which defines how to handle the user’s traffic.  

The default ACL is typically set up as follows: 

• Profile Name – Default
• ACL Type – Basic 
• Action – Permit
• Source MACs – Select Authorized MAC(s)
• MAX MACs – Set to 1 so that only the MAC attempting to be authorized is allowed.

PERMIT-ALL-TRAFFIC ACL Profile

You will need to define an ACL profile to be used once a user or device is authorized that does not restrict the traffic on the port.

The PERMIT-ALL-TRAFFIC ACL is typically set up as follows: 

• Profile Name: PERMIT-ALL-TRAFFIC
• ACL Type: Basic 
• Action: Permit
• Source MACs: Select Authorized MAC(s)
• MAX MACs: Set to 1 so that only the MAC attempting to be authorized is allowed.

DATA Floor 1 Example Service Profile

This profile shows an example profile that might be used for User Data for a particular floor.  It will specify the VLAN for that particular geographic location.  The policy engine will profile the user or device, characterize it and apply the profile match for DATA and the profile assigned to the port that is prefixed with DATA will be selected.  The Policy engine only knows it’s user data, but doesn’t need to know the specific VLAN.

• Profile Name – Strong conventions should be used in profile naming to ensure an architecture that is easy to maintain.  Refer to recommended filter id profile match names above.
• Service Type – The service type must be Bridged N:N.
• 802.1q VLAN – Define the proper VLAN ID associated with this service type.
• Untagged – The service is typically untagged for user data ports.
• ACL Profile Name – Should be set to default.  The policy engine later will replace this with the ACL appropriate to the compliance state of the port.

An example is shown below of a data profile for a different floor, only differing by the VLAN to be used for that particular floor or geographic area.  Ports within an area would have in their NAC profile the appropriate Service Profile(s) for that area.  

The policy engine would simply use a profile match of DATA and the appropriate VLAN would be assigned.

Voice Floor 1 Example Service Profile

Each different service (which is on a different VLAN) will need a separate service profile.  In this example, a Voice profile is shown for VoIP phones.


 

• Profile Name – Strong conventions should be used in profile naming to ensure an architecture that is easy to maintain.  Refer to the recommended filter ID profile match names above.
• Service Type – The service type must be Bridged N:N.
• Class Of Service – Voice should always be set to nrtVBR for proper prioritization of the voice traffic to ensure good quality audio.
• 802.1q VLAN – Define the proper VLAN ID associated with this service type.
• Tagged – The service is typically Tagged for user voice ports.
• LLDP Application Type – The LLDP Application type should be set to 1 which typically indicates the "voice" VLAN to the phone over LLDP.
• ACL Profile Name – Should be set to default.  The policy engine later will replace this with the ACL appropriate to the compliance state of the port.

Port NAC Profile

NAC profiles allow a set of service profiles to be assigned to a port.  The policy engine will pick from the profiles assigned to the port.

The following attributes are key to proper operation: 

• Default VLAN – Use this multi-click box to assign all relevant service profiles.
• Enable MAC Bypass – If you intend to allow any devices to be authenticated via MAC bypass which is typically needed for devices that don’t support 802.1x, such as most phones and printers, you should enable MAC Bypass.
• Enable PAE Dynamic Services – Must be enabled to allow port authorization on the port.
• Enable Filter ID – This is required for assignment of the profile by RADIUS or a policy engine.
• MAB Startup Delay – The startup delay should typically not be changed from the 30 seconds as this could change the order which authentication methods occur.
• Enable Authentication Fail – This attribute allows the specification of a quarantine VLAN which will be assigned to the user port if RADIUS sends back an ACCESS REJECT message to an authentication attempt.

The example below shows that DATA (users) and/or VoIP phones may be attached to this port.  More could be assigned such as a printer or any other class of users or devices that you wish to categorize to a specific VLAN.  All relevant service profiles should be included.

NAC profiles should be created for each geographic region or area.

PAE Profile

Create a PAE Profile to be assigned to all ports where you wish to do 802.1x, MAB or have the policy engine manage the port.

• Admin State – Set the Admin State to Enabled, which enables 802.1x/MAB for the policy engine.
• Maximum Authorized Supplicants – Should be set to the number of 802.1x devices allowed to authorize on the port.  Typically, it never changed from the default of 1.  MAB devices and 802.1x devices are separately counted, so a phone and PC can still be authorized on the same port with the default value of 1.
  
  

LLDP Profile

The following attributes are key to proper operation: 

• Admin State – Must be set to Enabled to allow the system to send LLDP to the attached device.  Phones depend on this to get their VLAN information.
• LLDP-MED Capabilities – Enabled to allow sending of capabilities to far end.
• Network Policy – Must be enabled to allow the sending of the VLAN found in the Filter ID/Tunnel ID/Egress VLAN ID RADIUS attributes to be communicated to the attached device.
• LLDP VLAN Assignment Delay – It is critical that this be set to 60 to ensure that phones have sufficient time to get the LLDP data and get on the proper VLAN prior to getting an IP on the voice VLAN.  
• Power via MDI – Should be set if you have any devices that require LLDP to negotiate power settings.

Assign Profiles to Ports

When using a policy engine to do the configuration dynamically upon user login, all the ports on a floor or geographic region will usually all be set to the same Profile assignments.  The most efficient way to accomplish this is to use the Profile and Admin state tool to bulk assign profiles to ports.

First, highlight all the ports you wish to modify, right click, and then select Profile and Admin State: 

The user can then assign all the attributes of all the ports at the same time.
 

• Note: For all attributes you wish to change, check the associated checkbox.  Unchecked attributes are ignored and are not changed.  Never change the default profiles, create a new profile if the default profile does not meet your needs. Modifying the default profile can lead to unexpected outages.
• Change Admin State – Set to Enabled
• NAC Profile – Assign the NAC profile for this floor or geographic region.  
• Port Profile – Assign the profile of your choice, the default typically works in most cases.
• PoE Profile – Since you do not want to have to manage it port by port, in most cases it is best to assign a PoE profile with PoE enabled.  If the ONT does not support PoE, it will be ignored.  After SR27 the default PoE profile is for PoE to be enabled.
• RSTP Profile – Assign the profile of your choice.  Default in many cases is adequate.  RSTP configuration should be based on the RSTP AppNote.
• PAE Profile – Assign the profile created in the steps above.
• LLDP Profile – Assign the profile created in the steps above.

PAE/MAB and PON Protection

Whenever PAE or MAB are used with PON Protection, special procedures are needed to ensure that the PON Sync Channel is properly configured on the PON Protection Group.  The sync channel is used to sync the authorized MACs, and dynamic VLAN assignments on ports.  For the sync channel VLAN to properly communicate, at least one ONT on the Primary PON must have a default service profile assignment to the sync VLAN with PAE/MAB disabled in the NAC profile.

If the user does not already have an ONT using the sync VLAN it is recommended that you create a sync ONT that does not have to be equipped that has the sync NAC profile assigned to the port.  PAE cannot be enabled on a port which is being used as the sync VLAN assignment.

The first step is to create an AnyMAC ACL to be placed onto the ports if you do not already have one.  This will be needed in a later step.

Only one sync VLAN is needed per OIU/QOIU card.

The user needs to create a Service Profile with the VLAN that will be used for the Sync Channel VLAN.  This VLAN is used to exchange sync messages to sync state between the active and standby link.  Failure to set up the sync channel will result in much slower switches and more service outages upon a switch.

Assign the proper VLAN for the sync channel to the 802.1q VLAN field of the service profile.  Make sure you assign the Sync Channel Any MAC ACL to the ACL profile field of the service profile.

Create a NAC profile to place the Sync Channel profile into.

It should include the Service profile that was created in the Enable Default VLAN of the NAC profile.  Ensure the Enable MAC Bypass and Enable PAE Dynamic Service are NOT enabled/checked.

Add an ONT to the Primary PON of the protection group.  The ONT does not have to be present, a "dummy ONT" can be created to carry the sync channel if one does not exist on the PON with the correct configuration.
 

Above, the user can see the created dummy ONT on the PON for the sync channel.  This ensures the VLAN is present on the PON so that sync traffic can pass.   A path for layer 2 traffic must exist between the Primary PON and Secondary PON (possibly on another OLT) so that sync traffic can flow.

Assign the NAC profile with the sync channel VLAN onto one or more ports of the ONT.

The VLAN of the sync channel can be configured in the Protection Groups dialog.

Monitoring Dynamic Assignments

When the Policy Engine dynamically assigns the Service profiles to lines, this is tracked by the system and is available in the EMS GUI.

The user can reach the dynamic services viewer by clicking on a PON, ONT, or Port and right clicking and selecting the Dynamic Services menu.  The Dynamic Services Dialog will be displayed along with any dynamic assignment within the scope (PON/ONT/Port).

In the dialog above, you can see that the port has two dynamic services assigned by the policy engine, one for data and one for voice as is typical when a PC is behind a phone on a single port.

Additionally, it should be noted that as services are assigned to the port, if there is also an IFALIAS string defined and sent by the policy engine, the system will display it in the User Label field.  If two services are on the port, then both IFALIAS strings will be displayed with a ‘+’ in between.  In the example below, both a VoIP phone and PC have been assigned to a port by the Policy Engine and both are reflected in the User Label.

The user can see which MAC addresses are assigned to each service.

Troubleshooting Radius Requests

The first thing to remember about the radius requests is they will all go up the Management VLAN.  Ensure that you have a route from the management VLAN to the Radius server.  If not, the EAPOL requests will be blocked.

There are two types of statistics for diagnosing what is going on with Radius authentication.

The PAE Statistics will cover the exchanges between the supplicant (end device) and the OLT for 802.1x.  The Diagnostics tab will contain the counters associated with the Radius Authentication exchange.

You can also use the PAE Counters to understand what is going on with the exchange between the supplicant (end device), the OLT, and the Radius Server.

The user can get statistics for the PAE by going to the Ports View, right-clicking on the port, and selecting PAE Property from the right-click menu.

The Status Tab will give you the high level state of the Authentication Process.

Authenticator PAE State lets you know the current state of the PAE State Machine

• Initialize – Generally a transient state. Can occur when the RADIUS server denies authentication, the port’s MAC is inoperable, or the state machine is initializing. Other transient states include Disconnected, Connecting, Authenticating, Aborting, and Held. If any of these states are not transient, contact your next level of support.

• Authenticated and Force Authentication – These states allow traffic to flow.
• Force Unauthentication – blocks all traffic on the port.

The Backend Authentication State lets you know what is going on within the authentication process. 

Displays the back-end authentication state received from the RADIUS server. Possible values are:

• Request – The RADIUS server received an authentication request.
• Response – The RADIUS server has sent an authentication response.
• Success – RADIUS authentication succeeded.
• Fail - RADIUS authentication failed.
• Timeout – Communication with the RADIUS server timed out.
• Idle – Following its initialization, the authenticator PAE is idle. It hasn’t sent any authorization requests yet.
• Initializing – The authenticator PAE is initializing.

The Authentication Controlled Port status lets you know whether the port is currently Authorized or Unauthorized.

The Statistics Tab can be consulted to get more information to troubleshoot a connection.

If the Transmitted EAPOL counter is incrementing, it means the OLT received EAPOL requests from the attached device on the port and is forwarding them to the Radius server.  If the EAPOL counters are zero, then no requests have been received from the end device.  The first message sent from the Supplicant is EAPOL Start, so this counter should be at least 1 if a request has been received.  If this counter is zero, ensure that 802.1x is enabled, and that the correct PAE profile is assigned to the port.    Please note these counters are reset on every run of the state machine and the MAC will be zeroed when the state machine starts over.

The Diagnostics Tab will give the results of the Radius / Authenticator exchanges between the OLT and RADIUS.  The most important counter to watch is the "Backend Authentication Successes" and "Fails" as this will indicate whether the authenticator is allowing the supplicant access or not.

For MAB/PAE Circuits, you can determine some information about the state of the port from the Dynamic Services view: 

When the Network VLAN on a MAB/PAE port is shown as 4095, then that implies that no service has been assigned by the policy engine.  If VLAN 4095 is present and a MAC address is seen, it means that the port is in the process of authentication or has failed authentication.   Further information can typically be gleaned about what is going on from viewing this port on the policy engine as it will typically be logged there as failing authentication.

When configuring the Policy Server to interface with the OLT, it is best practice to ensure the user can ping the RADIUS server within the policy engine prior to enabling PAE so that you know basic network connectivity exists to the authenticator.

RADIUS Authentication of CLI Users

RADIUS can be set up to authenticate CLI users which allows authentication from a global database rather than the local database of each OLT.

Several steps need to be performed: 

• Creation / Import of the Tellabs dictionary
• Creation of RADIUS user Entries
• Configure the OLT to use CLI RADIUS Authentication

Download or import the current dictionary.tellabs.  This defines the attributes for the Tellabs Vendor, the Tellabs-UserRole attribute, and the supported roles for the product.

Then the next step is to create the user in the RADIUS database.  This varies by vendor and this example shows a typical User Entry for a CLI User authentication.

 adminuser1 Cleartext-Password:="adminpass1"

The last step is to set up the CLI to use RADIUS authentication by configuring it on the OLT.  This is done from the OLT->right click-> properties -> Security Tab.

Set the authentication protocol type, then enter the RADIUS server(s) IP shared key and RADIUS server port.  After that, press apply and the OLT will utilize RADIUS authentication and be assigned on authentication the proper role in authentication.

SNMP Setup

Policy Engines tend to use SNMP to do some level of discovery about the system, and in the case of some agents, they depend on it to do some functions.  It is recommended that te user configures the Tellabs OLT to enable SNMP and configure the Policy engine IP as a trap destination.  The procedure for enabling SNMP on Tellabs OLTs is found in the document: 

         ENG-010622 Using SNMP on Tellabs OLTs

Summary

Using the Radius Filter-id to return the configured services profile can be a very powerful tool.  It allows users to roam within the network and still get their individualized list of services assigned to whatever port they log into.  This allows for a very dynamic and robust network to meet the user’s needs.

Video