wp 8021x authentication ldap

7/23/2019 Wp 8021x Authentication Ldap

http://slidepdf.com/reader/full/wp-8021x-authentication-ldap 1/26

I R O N S H I E L D W H I T E P A P E R

WHITE P APER : 802.1X PORT A UTHENTICATION WITH LDAP

Written By: Philip KwanMarch 2003

March 2003 ©2003 Foundry Networks, Inc. Version 1.0.0 All Rights Reserved.




WHITE P APER : 802.1X PORT A UTHENTICATION

WITH LDAP

SummaryLightweight Directory Access Protocol (LDAP) is one of the most widely used authentication directories in modernnetworks. This white paper describes Foundry’s 802.1X Port Authentication feature and how it works withOpenLDAP and Interlink Network’s Secure.XS server.

Contents

NOMENCLATURE ..................................................................................................................................................................3

RELATED PUBLICATIONS...................................................................................................................................................3

TRADEMARKS ........................................................................................................................................................................3

802.1X PORT AUTHENTICATION BASICS........................................................................................................................4

LDAP..........................................................................................................................................................................................5

SAMPLE OPENLDAP IMPLEMENTATION.......................................................................................................................5

I NSTALLING OPENLDAP..........................................................................................................................................................6

RADIUS AUTHENTICATION PROXY.........................................................................................................................................7

Installing Secure.XS.............................................................................................................................................................7

Secure.XS Windows Version 6.0.3 .....................................................................................................................................12

CONFIGURING 802.1X PORT AUTHENTICATION.......................................................................................................13

OTHER 802.1X COMMANDS ...................................................................................................................................................14

MULTIPLE HOST SITUATIONS .................................................................................................................................................15

CONFIGURING WINDOWS CLIENTS..............................................................................................................................16

TESTING THE CLIENT CONNECTION .......................................................................................................................................17

ADDITIONAL TIPS...................................................................................................................................................................18

OTHER 802.1X CLIENTS TESTED............................................................................................................................................18

CONFIGURING FOUNDRY’S DYNAMIC VLAN FEATURE.........................................................................................19

CONFIGURING LDAP USER ACCOUNTS .................................................................................................................................20

CHECKING THE RADIUS DICTIONARY..................................................................................................................................21

CREATING PORT-BASED VLANS.....................................................................................................................................23

TESTING THE DYNAMIC VLAN FEATURE...................................................................................................................23

DisclaimerFoundry Networks, Inc. makes no claims or guarantees as to the accuracy of installing and supporting InterlinkNetworks Secure.XS product. Refer to Interlink Networks for complete installation guidelines and product

information regarding Secure.XS components mentioned in this white paper.

Foundry Networks, Inc. makes no claims or guarantees as to the accuracy of installing and supportingMeetinghouse’s AEGIS Windows and MAC OS clients. Refer to Meetinghouse Data Communications for completeinstallation guidelines and product information regarding AEGIS 802.1X clients mentioned in this white paper.

Foundry Networks, Inc. makes no claims or guarantees as to the accuracy of installing and supporting OpenLDAPRefer to the OpenLDAP community at www.OpenLDAP.org for complete installation guidelines and productinformation.

March 2003 ©2003 Foundry Networks, Inc. 2

Version 1.0.0 All Rights Reserved.





WITH LDAP

Nomenclature

This guide uses the following typographical conventions to show information:

Italic highlights the title of another publication and occasionally emphasizes a word or phrase.

Bold highlights a CLI command.

Bold Italic highlights a term that is being defined.

Underline highlights a link on the Web management interface.

Capitals highlights field names and buttons that appear in the Web management interface.

NOTE: A note emphasizes an important fact or calls your attention to a dependency.

Related PublicationsThe following Foundry Networks documents supplement the information in this guide.

Foundry Security Guide - provides procedures for securing management access to Foundry devices and forprotecting against Denial of Service (DoS) attacks.

Foundry Enterprise Configuration and Management Guide - provides configuration information for enterpriserouting protocols including IP, RIP, IP multicast, OSPF, BGP4, VRRP and VRRPE.

Foundry Switch and Router Command Line Interface Reference - provides a list and syntax information for all theLayer 2 Switch and Layer 3 Switch CLI commands.

TrademarksMicrosoft Windows 2000 and Microsoft Windows XP, are trademarks or registered trademarks of MicrosoftCorporation.

Secure.XS is a trademark or registered trademark of Interlink Networks.

AEGIS Client is a trademark or registered trademark of Meetinghouse Data Communications.

Foundry Networks, BigIron, EdgeIron, FastIron, NetIron, ServerIron, and the “Iron” family of marks aretrademarks or registered trademarks of Foundry Networks, Inc. in the United States and other countries.

All other trademarks are the properties of their respective owners.







WITH LDAP

802.1X Port Authentication BasicsFoundry’s implementation of 802.1X Port Authentication is based on a series of standards:

• RFC 2284 PPP Extensible Authentication Protocol (EAP)• RFC 2865 Remote Authentication Dial In User Service (RADIUS)

• RFC 2869 RADIUS Extensions

There are three components that are used to create an authentication mechanism based on 802.1X standards:

Client/Supplicant, Authenticator, Authentication Server.

Client/Supplicant The client, or supplicant, is the device that needs authenticating to the network.It supplies the username and password information to the Authenticator. Theclient uses the Extensible Authentication Protocol (EAP) to talk to the Authenticator.

Authenticator The Authenticator is the Foundry device performing the 802.1X Port Authentication controlling access to the network. The Authenticator receives theusername and password information from the client, passes it onto the Authentication Server, and performs the necessary block or permit action basedon the results from the Authentication Server. The Authenticator uses RADIUSto speak to the Authentication Server.

Authentication Server The Authentication Server validates the username and password informationfrom the Client and specifies whether or not access is granted. The Authentication Server may also specify optional parameters to control things

such as VLAN access. Foundry’s 802.1X implementation currently supportsstandard RADIUS Authentication Servers.

802.1X Clients use the Extensible Authentication Protocol (EAP) and EAP OverLAN (EAPOL) to securely encapsulate thecommunications between the Client and Authenticator. The Authenticator usesRADIUS to communicate with the Authentication Server.

Before the Client is authenticated, thenetwork port is set to the uncontrolled (unauthorized) state and only allows EAPOL

authentication traffic between the Client andthe Authentication Server. All other normaldata traffic is blocked. When the client

authentication is complete and access isgranted, the controlled port is set in theauthorized state to grant full networkaccess.

Figure 1. Port Authentication Process







WITH LDAP

If a non-802.1X client is connected to an 802.1X protected port, the Client will not recognize the EAPOL pollingtraffic from the Authenticator and authentication will fail. The client will not be granted network access. If an802.1X EAP-MD5 enabled client is connected to a non-802.1X port, it will attempt to send an EAP start frame tothe Foundry device. When the device doesn’t respond to the EAP packet, the Client considers the port to be

authorized and starts sending normal traffic.

By default, Foundry devices place all ports in the authorized state, allowing full network access. When 802.1 Port Authentication security is implemented, all 802.1X enabled ports are switched to the unauthorized state toprevent full network access. Foundry devices support the EAP-MD5 standard between the client and itself.

NOTE: For more information on Foundry’s implementation of 802.1X, please refer to the following resources:802.1X White Paper: http://www.foundrynet.com/solutions/appNotes/PDFs/802.1XWhite_Paper.pdf

LDAPLightweight Directory Access Protocol (LDAP) is a directory service that is based on the X.500 Directory Servicesmodel. LDAP is an information repository as well as a protocol for querying and manipulating the data in anLDAP directory. The LDAP Directory is a specialized data repository that is tuned to provide fast responses toqueries: reading, browsing, and searching. It is made up of attribute-based and descriptive information thatsupports complex searches and filtering activities. Directories are also designed to support large volumes ofcomplex updates and complex replication schemes to support local and global architectures.

OpenLDAP is an open-source LDAP application that is developed by a community of users. OpenLDAP is

considered by many IT professionals as a robust, commercial-grade LDAP solution and is used by enterprisedirectory services. It uses schemas to allow for flexible configuration of directory information that can housemany different types of corporate and personal information – allowing businesses to centralize and search

directory trees.

NOTE: For more information on OpenLDAP, please refer to the following site: www.openldap.org

Sample OpenLDAP ImplementationDue the many different LDAP implementations and possible schema configurations, this White Paper will use abase configuration of OpenLDAP to illustrate Foundry’s 802.1X Port Authentication feature working with an LDAPdirectory. Production LDAP servers may be more complex with regards to the directory information and theschemas supported. The procedure will be similar in most LDAP installations but the exact configuration steps

will vary.

Due to the lack of native RADIUS support in OpenLDAP and other LDAP directories, many RADIUS vendors haveproduced LDAP hooks to allow their RADIUS servers to authenticate against LDAP directories. For this sampleLDAP installation, Interlink Networks Secure.XS server was used as the intermediary between the Foundry deviceand the OpenLDAP server.



http://www.foundrynet.com/solutions/appNotes/PDFs/802.1xWhite_Paper.pdf

http://www.openldap.org/


http://www.foundrynet.com/solutions/appNotes/PDFs/802.1xWhite_Paper.pdf





WITH LDAP

Figure 2. Sample LDAP Installation Topology

Installing OpenLDAPFor installations that will be using Foundry’s 802.1X Port Authentication with an LDAP directory for authentication,an existing production LDAP directory with the necessary user accounts will most likely be in place. This sectiondescribes the required steps for creating an OpenLDAP server for our sample implementation and can be skippedif a production LDAP directory exists.

The sample LDAP directory will allow anonymous searches without additional security measures – such as userand password credentials for accessing the LDAP directory. To simplify LDAP lookups, passwords were stored in “clear” format in the LDAP directory. Production systems should encrypt LDAP passwords.

Step 1: Prepare a host with the necessary UNIX or Windows operating system – the OS selected must besupported by OpenLDAP. For the sample installation, Red Hat Linux version 8.0 was used with the latest securitypatches.

Step 2: Download, compile, and install OpenLDAP. The source files can be found at www.openldap.org and theinstallation guide can be found at the following web site: www.openldap.org/doc/admin/quickstart.html

Step 3: Load the necessary object classes from the schema to populate the LDAP directory with the necessaryobjects. For the sample installation, the OpenLDAP person and inetOrgPerson object classes were loaded.

These two object classes supported the basic user account information that will be used to authenticate the clientusers.

Step 4: Load any additional management tools to help manage the LDAP directory. GQ version 0.4.0 wasloaded on the sample OpenLDAP server to support a graphical user interface. GQ’s graphical interface makesbrowsing and modifying the LDAP directory much easier.




http://www.openldap.org/doc/admin/quickstart.html







WITH LDAP

Step 5: Populate the LDAP directory with the necessary user information. The directory can be populatedthrough a script file or through the GQ tool. For the sample database, the following parameters were used topopulate the LDAP directory with user information:

Object Class Parameter Example Valuesdn cn=john smith,dc=foundry,dc=comobjectClass person, inetOrgPersonsn smithcn john smithuserPassword testpasswordtelephoneNumber 408 555-1212displayName John SmithgivenName johnmail [email protected] jsmith

Step 6: Test your LDAP server with the GQ client to ensure that the LDAP directory can be browsed, searched,and modified.

For 802.1X Port Authentication, the two most critical objects are the User ID (uid) and the User Password(userPassword) parameters. The authentication proxy will compare the username and password entered bythe client against the uid and userPassword parameters in the LDAP directory to authenticate the client.

NOTE: For more information on installing OpenLDAP, please refer to the following web sites:http://www.openldap.org http://www.openldap.org/doc/admin/quickstart.html http://www.openldap.org/doc/

RADIUS Authentication ProxyDue LDAP’s lack of native RADIUS support, an authentication proxy is required with LDAP installations to supportthe Foundry device’s RADIUS authentication call. Interlink Networks Secure.XS server was used in the sampleinstallation to perform the RADIUS-to-LDAP authentication. There are many other RADIUS products that willperform similar functions using LDAP plug-ins. For more information on using your RADIUS server for LDAPauthentication, contact your RADIUS vendor.

Installing Secure.XSInterlink Networks Secure.XS version 6.0.3 for Windows was installed on a Windows 2000 Server (with SP3) forthe sample installation. The following steps illustrate a basic installation of Secure.XS and the configuration stepsrequired to allow Secure.XS to proxy RADIUS authentication requests from the Foundry device to the LDAPdirectory.

Depending on the products and versions used for the RADIUS authentication proxy, these steps may or may notapply. Please check with Interlink Networks for the latest installation guidelines if Secure.XS will be used for yourimplementation.





http://www.openldap.org/doc/

http://www.openldap.org/doc/







WITH LDAP

Step 1: Download and install the Secure.XS evaluation software. Follow the installation instructions in the self-extracting installation file. The source files can be found at Interlink Networks’ web site:www.interlinknetworks.com

Step 2: If necessary, obtain the necessary installation license from Interlink Networks and install the license toactivate the software.

Step 3: Start the Secure.XS Server Manager utility and log into the management interface using the defaultadministrator account (adminaaa) and password (adminaaa). The Server Manager is found under the

Start/Programs/Internlink Networks menu.The Secure.XS Server Manager screen is displayedas shown in Figure 3.

Figure 3. Secure.XS Server Manager Screen

Step 4: Since this is a new installation, make sure the local configuration files are loaded and start theSecure.XS server.

• Select Load Configuration from the menu,check the localhost option, and click on theLoad button. The server will begin to loadthe local configuration files and a TransferComplete message will be displayed whenthe files are completely loaded.

Figure 4. Loading Local Configuration



http://www.interlinknetworks.com/

http://www.interlinknetworks.com/





WITH LDAP

• Select Administration from the menu and

choose the Start button to enable theSecure.XS server. Once the server issuccessfully started, the status window willhave the localhost checked and the green “Go ” icon displayed.

Figure 5. Starting Secure.XS Server

Step 5: Create a new RADIUS Access Client for each Foundry device that will be authenticating clients againstthe LDAP directory.

• Select Access Devices from the menu andchoose the New Access Device option.

• Enter the information for the Foundry Device:o Name: IP Address or DNS Name of

the Foundry deviceo Shared Secret: RADIUS secret set

on the Foundry device (must match)o Vendor: Select Generic o Options: Leave options unchecked

Repeat this step for each Foundry device that will be

authenticating against the LDAP directory.

Figure 6. Creating An Access Device







WITH LDAP

Step 6: Create the Realm that will be used to support the authentication process. Realms are logical groupingsof users and can parallel the corporate DNS structure. An example of a Realm can be the suffix for a user’s emaiaccount. For example, the email account [email protected] is configured with a realm of foundry.com.

• Select the Local Realm menu option and

choose New Local Realm.• Enter the New Local Realm information:

o Name: Realm name that will be usedafter the User ID. e.g. foundry.com

o Authentication Type: Select ProLDAP o DNS of File Name: For ProLDAP

authentication, this field is usedfor description purposes. Enter adescriptive string for this field.

o Protocol: Select All o Session Tracking: Can be either

Yes or No to enable or disableaccounting records.

o Filter Type: Select CIS (not casesensitive)

• Select the New LDAP Directory drop down

box and select the New LDAP Directory option. The LDAP Directory screen will bedisplayed allowing the hooks to be definedinto the LDAP directory.

Figure 7. Creating New Local Realm

• On the LDAP Directory screen, enter the following configuration information to setup the LDAP link:o Directory Name: A unique identifier used to describe the LDAP Directory link. Eg. Foundry

OpenLDAPo Host: The IP Address of the LDAP server or its DNS Name o Port: The LDAP port number that is supported by the LDAP server (default LDAP port is 389)o Administrator & Password: The distinguished name (dn) of the directory administrator and its

password. These two fields are only required if the LDAP directory doesn’t support anonymous

searches. For the sample installation, the OpenLDAP directory was setup to allow anonymoussearches.

o Search Base: The dc in the LDAP database to begin searching. Enter the same dc information thatwas used to create the LDAP directory. For example dc=foundry,dc=com.

o Filter: Enter the LDAP object parameter that will be used to authenticate against the LDAP directory.The sample installation will match on the LDAP directory’s User ID (uid) field.

o Authentication Type: Set to Search

• Select the Save button to create the LDAP directory link.

• Select the Create Button to create the new Local Realm.



mailto:[email protected]

mailto:[email protected]





WITH LDAP

Step 7: Create a NULL Realm to allow the Secure.XS server to provide default support for the EAP-MD5authentication requests from the Foundry device.

• Select the Local Realm menu option and choose

New Local Realm.• Enter the New Local Realm information:

o Name: Enter NULL o Authentication Type: Select EAP o DNS of File Name: For EAP authentication,

this field is used for description purposes.Enter a descriptive string for this field.

o Protocol: Select All o Session Tracking: Can be either Yes or No

to enable or disable accounting records.o Extended Parameters: Select MD5-

Challenge • Click the Create button to create the Null Realm.

Figure 8. Null Realm Creation

Step 8: Save the configuration to the localhost.

• Select the Save Configuration option from the

menu.

• Check the localhost option.

• Click the Save button.

The Secure.XS server will transfer the changes to thelocal configuration files. Once the process iscomplete, the server will display the TransferComplete message.

Figure 9. Saving The Configuration To The Localhost

Step 9: Stop and Start the Secure.XS server to enable the new RADIUS clients and Realms. The Stop andStart controls are found in the Administration menu option.







WITH LDAP

Secure.XS Windows Version 6.0.3

The following CLI installation steps are required to complete the configuration process for LDAP support.Interlink Networks Secure.XS will not require these additional CLI configuration steps after version 6.0.3. For

complete installation instructions, please contact Interlink Networks customer support.

Step 1: Stop the Secure.XS server by selecting Stop from the Administration menu.

Step 2: Using a text editor such as Wordpad, open the authfile in the \program files\interlinknetworks\aaaserver\raddb installation directory. This directory tree may be different if the application was installed in adirectory other than the default installation directory.

• After the “Filter-Type…” entry, add thefollowing line:

Retrieve-only true

• Highlight the entire NULL section and Copy

it into the clipboard. You will need these fourlines in the next step.

• Save the file in text format without the “.txt”extension.

Figure 10. Modifying the AUTHFILE

Step 3: Using a text editor, open the EAP.authfile in the \program files\interlinknetworks\aaaserver\raddb installation directory. This

directory tree may be different if the application wasinstalled in a directory other than the defaultinstallation directory.

• Replace the existing NULL section with the Nullsection copied from the previous step (authfile).

• Change the NULL label to the name that was used

for the new LDAP Realm Name in step 6 on page10. For example foundry.com.

• Save the file in text format without the “.txt”extension.

Figure 11. Modifying the EAP.authfile







WITH LDAP

Step 4: Rename the existing radius.fsm file in the \program files\interlinknetworks\aaaserver\raddb installation directory to radius.fsm-original. Make a copy the 2stage_wireless.fsm fileand rename it to radius.fsm.

Step 5: Start the Secure.XS server by selecting the Start option from the Administration menu.

NOTE: After the changes are made to the authfile and EAP.authfile, any further changes made to the Secure.XSserver and saved to the local configuration files may overwrite the changes manually made in this section. Ifchanges are made using the Server Manager GUI after this step, please check the contents of the authfile andEAP.authfile to make sure the correct configuration is set.

NOTE: The LDAP Server must be configured to return the password when the User ID (uid) parameter issearched. It should also be programmed to return any VLAN information that is stored in the LDAP record. Thebase installation of OpenLDAP configured in this sample installation will return the necessary information whenqueried.

Configuring 802.1X Port AuthenticationFoundry devices will support up to eight RADIUS servers and will authenticate against them in the order theywere added to the device’s configuration. To configure a Foundry device to support 802.1X Port Authentication,

the following procedures are required:

• Configure the Foundry device (Authenticator) to interact with one or more Authentication Server(s)(RADIUS, RADIUS proxy servers, etc.).

• Configure the Foundry device to act as the Authenticator.• Configure the Foundry device’s interaction with the Client device (optional step).

Step 1: Configure the Foundry device to use RADIUS for authenticating 802.1X security and define one or moreRADIUS or RADIUS proxy servers.

Syntax: [no] aaa authentication dot1x default <radius | none>

BigIron(config)# aaa authentication dot1x default radius

Configure the device to use one or multiple RADIUS or RADIUS proxy servers. Set the authentication andaccounting port numbers to match the RADIUS server’s settings, and specify the secret key to authenticate tothe RADIUS server. The secret key string must be identical to the secret key string used on the RADIUS proxyserver (Secure.XS server).







WITH LDAP

Syntax: radius-server host <ip-addr> | <server-name> [auth-port <number> acct-port <number> default key<string> dot1x]

BigIron(config)# radius-server host 192.168.100.100 auth-port 1812 acct-port 1813default key mysecretpassword dot1xBigIron(config)# radius-server host 192.168.101.150 auth-port 1812 acct-port 1813default key mysecretpassword dot1x

Step 2: Enable the 802.1X authentication feature on the Foundry device, and enable the necessary ports for802.1X Port Authentication. This enables the Foundry device to act as an 802.1X Authenticator.

Syntax: [no] dot1x-enable

BigIron(config)# dot1x-enable

To configure 802.1X for individual ports, you can use the “enable” command with the port number. A range can

also be specified to help make the configuration work faster. Be careful not to add any uplink ports or ports forcritical servers that do not require 802.1X Port Authentication – access may be lost to these hosts.

BigIron(config-dot1x)# enable Ethernet 2/1 to 2/24BigIron(config-dot1x)# enable Ethernet 3/1 to 3/24BigIron(config-dot1x)# enable Ethernet 4/1 to 4/10BigIron(config-dot1x)# enable Ethernet 4/17 to 4/24BigIron(config-dot1x)# write memory

Step 3: For all interfaces using 802.1X authentication, enable the control mode to “force-authorized”, “force-unauthorized”, or “auto”. Auto leaves the controlled port in unauthorized mode until the RADIUS server validatesthe authentication.

BigIron(config)# interface e 3/1BigIron(config-if-3/1)# dot1x port-control auto

The switch is now enabled for 802.1X Port Authentication. Make sure the RADIUS server is properly configuredto authenticate each user.

Other 802.1X CommandsSome other important 802.1X commands and options include:

Syntax: show dot1x Displays 802.1X configuration information

Syntax: show dot1x config <portnum> Displays detailed 802.1X configuration for a portSyntax: show dot1x statistics <portnum> Displays 802.1X statistics for a portSyntax: clear dot1x statistics all | <portnum> Clears 802.1X statistics for all ports or a specific port







WITH LDAP

Multiple Host SituationsFoundry’s 802.1X Port Authentication defaults to one device per port. For installations that are using more thanone host per 802.1X-enabled port, the following commands should be reviewed.

Syntax: [no] dot1x multiple-hosts Allows multiple hosts on an 802.1X enabled portSyntax: [no] timeout security-hold-time <seconds> Defines the amount of time the port is locked when

multiple hosts are detected on a port configured for only

one host. The default is 60 seconds.

If the multiple-hosts option is used, the port will allow multiple devices to access the network once the first802.1X client authenticates successfully. When the authenticated client logs off the network and terminates theauthenticated session, the port will deny access to the remaining hosts. Another client must authenticatesuccessfully to enable the port for multiple-host access again.

NOTE: For more information on MAC Address Locking and 802.1X authentication, refer to the Foundry Switchand Router Command Line Interface Reference and the Foundry Security Guide .







WITH LDAP

Testing The Client ConnectionTo test the Windows client, connect the host to the Foundry device’s 802.1X-enabled port. After a short period,the port and the client’s NIC will synchronize and the 802.1X EAP-MD5 authentication process will begin. As the

Client completes its synchronization process, the Network Icon in the task bar will show the Local AreaConnection speed. The EAP-MD5 port authentication process will begin and the user will be prompted to entertheir Local Area Connection credentials (username and password).

• Enter the User Name and Password informationrequired to authenticate to the LDAP directory. The full

user ID and the Realm suffix that was defined on theSecure.XS server must be entered. Example:

[email protected] • The Logon Domain information is not required.

Figure 14. Local Area Connection Credential Request

If the LDAP Directory server validated the authentication credentials entered, the client is allowed onto thenetwork. If the LDAP Directory server did not validate the authentication credentials, a message similar to thefollowing will be displayed:

The EAP-MD5 authentication will time out and the user will beprompted for their authentication credentials again.

Figure 15. Failed 802.1X Authentication Message







WITH LDAP

Additional TipsIf the attempt to obtain a DHCP address fails due to a timing issue (the authentication process was not successfubefore the DHCP request timed out) the client may not have a proper DHCP address. Once authentication is

successful and a network connection is granted by the Foundry device, Windows 2000 Professional (SP3 with all802.1X patches) and Windows XP (SP1) clients should renegotiate a DHCP address with the DHCP server after ashort period of time.

If this is not the case, you can manually release and renew the DHCP address with the following command linecommands:

C:\> ipconfig /releaseC:\> ipconfig /renew

These commands can also be placed in a batch file and placed onto the desktop to speed the process of renewinga DHCP address. An example of the batch file commands are:

ipconfig /releaseipconfig /renewpauseexit

If you need to manually control the Local Area Connection authentication prompt, temporarily disconnect thenetwork cable from the client for 10 seconds and then reattach it. This will trigger a new EAP-MD5authentication process and allow the user to enter the authentication credentials again.

Other 802.1X Clients Tested At the time of this writing, Foundry Networks has also tested the following 802.1X EAP-MD5 clients:

• AEGIS Windows Client version 2.0.0 from Meetinghouse Data Communications. The AEGIS WindowsClient offers a single sign-on solution. For more information on this client, visit: www.mtghouse.com

• AEGIS MAC OS Client version 1.2.1 from Meetinghouse Data Communications. For more information onthis client, visit: www.mtghouse.com



http://www.mtghouse.com/








WITH LDAP

Configuring Foundry’s Dynamic VLAN FeatureWith software release 07.6.03, a new feature called Dynamic VLAN Assignment is supported with Foundry’s802.1X Port Authentication. Dynamic VLAN Assignment allows network administrators to assign a specific VLAN

to an individual’s Windows User Account. When the individual successfully authenticates to the network using802.1X Port Authentication, they are automatically placed into their respective VLAN.

NOTE: This feature is supported on port-based VLANs only. This feature cannot be used to place an 802.1X-enabled port into a Layer 3 protocol VLAN. For more information on Foundry’s 802.1X Dynamic VLAN Assignmentfeature, refer to the 07.6.03 Foundry Switch and Router Command Line Interface Reference and Release Notes.

Foundry uses the following standard RADIUS attributes returned from the LDAP directory to place the port intothe proper VLAN:

Attribute Name Type ValueTunnel-Type 064 13 (decimal) – VLANTunnel-Medium-Type 065 6 (decimal) – 802Tunnel-Private-Group-ID 081 <vlan-name> (string) – either the name or the number

of a VLAN configured on the Foundry device

The following occurs under Dynamic VLAN Assignment:

1. When the user enters their 802.1X credentials, the Foundry device sends the information to the LDAP proxyserver using the RADIUS protocol.

2. The RADIUS proxy server sends the authentication request to the LDAP directory and uses the user name tomatch on the uid stored on the directory server. If the authentication is successful, the required VLANinformation is passed from the LDAP directory to the RADIUS proxy server. Which in turn, sends it to the

Foundry device.3. The Foundry device reads the three RADIUS attributes returned to validate the Tunnel-Type and the Medium-

Tunnel-Type. If these attributes were set correctly, the Tunnel-Private-Group-ID attribute is compared to the VLANs defined on the Foundry device.

4. If a matching VLAN is found, the Foundry device assigns the port to the VLAN using the VLAN ID specified inthe Tunnel-Private-Group-ID. The user dynamically becomes a member of the Port-Based VLAN.

Conditions that may trigger an unsuccessful authentication and/or Dynamic VLAN assignment include:

• If the Tunnel-Type or the Tunnel-Medium-Type attributes in the RADIUS Access-Accept message do not havethe values specified above, the Foundry device will ignore the three Attribute-Value pairs. If theauthentication credentials supplied were valid, the Foundry device authorizes the port, but the port is not

dynamically placed in a VLAN. Otherwise, the client is not authorized.• If the Tunnel-Type or the Tunnel-Medium-Type attributes in the RADIUS Access-Accept message have the

values specified above, but there is no value specified for the Tunnel-Private-Group-ID attribute, the clientwill not be authorized.

• When the Foundry device receives the value specified for the Tunnel-Private-Group-ID attribute, it checks its

VLANs for a match using both the name and the numeric ID. If there is a match, the port is placed in the VLAN whose ID corresponds to the VLAN Name or ID. If there is no match, the client is not authorized.







WITH LDAP

Configuring LDAP User AccountsIn order to add the necessary RADIUS Tunnel Attributes to the LDAP Schema, the RADIUS server’s RADIUSschema needs to be added to the LDAP directory. For the sample installation using Interlink Networks’

Secure.XS server, the following steps were used to add the necessary RADIUS schema to the OpenLDAPdirectory.

NOTE: If 802.1X Dynamic VLAN Assignment is turned on, any user who does not have the RADIUS Tunnel Attributes set will be placed in the Default VLAN.

Step 1: Copy the Interlink Networks’ RADIUS schema file (iaaa-radius.schema) to the directory where theOpenLDAP schema files are stored. By default, OpenLDAP schema files should be located in the followingdirectory:

/etc/openldap/schema

Step 2: Modify the slapd.conf file to include the new RADIUS schema file. The slapd.conf file is located in the /etc/openldap/ directory. The modified file should include the following new line, “include

/etc/openldap/schema/iaaa-radius.schema”

EXAMPLE:

i ncl ude / etc/ openl dap/ schema/ core. schemai ncl ude / etc/ openl dap/ schema/ cosi ne. schemai ncl ude / etc/ openl dap/ schema/ i net orgperson. schemainclude /etc/openldap/schema/iaaa-radius.schema

Step 3: Stop and start the OpenLDAP server if necessary.

Step 4: Using the GQ viewer, scan the Schema tab. If the RADIUS schema loaded correctly, you should seemany new “aaa” object classes. The RADIUS object class required to support Foundry’s 802.1X Dynamic VLAN Assignment is “aaaPerson” and the attribute is “aaaReply”.

Step 5: For each user requiring Dynamic VLAN support, add the “aaaPerson” to their LDAP record’s supportedObjectClass list. This will enable the “aaaReply” attribute for returning the three RADIUS Tunnel attributes to theFoundry device: Tunnel-Type, Tunnel-Medium-Type, and Tunnel-Private-Group-ID.

Step 6: Modify the “aaaReply” attribute and create three RADIUS Tunnel attributes for each user. Configure theTunnel attributes as follows:

aaaReply attribute #1: Tunnel-Type=VLANaaaReply attribute #2: Tunnel-Medium-Type=IEEE-802

aaaReply attribute #3: Tunnel-Private-Group-Id =VLAN ID number or name







WITH LDAP

Step 7: For each user requiring Dynamic VLAN support, repeat steps 5 and 6.

Depending on the RADIUS server being used, the LDAP directory tunnel attributes may have to be entered using

tagged fields. Check with your RADIUS vendor to see if tagged fields are a requirement for the correct handling

of the tunnel attribute values. For the sample installation, Interlink Networks Secure.XS dictionary required thetunnel attributes to be tagged. The “:1:” tag was used to precede each tunnel attribute value.

EXAMPLE:aaaReply attribute #1: Tunnel-Type=:1:VLANaaaReply attribute #2: Tunnel-Medium-Type=:1:IEEE-802aaaReply attribute #3: Tunnel-Private-Group-Id =:1:10

Checking The RADIUS DictionaryEvery RADIUS server will have a dictionary that it uses to support the attributes and values. Depending on the

RADIUS vendor, the dictionary layout will vary. Using Interlink Networks Secure.XS server, the dictionary file islocated in the \program files\interlinknetworks\aaaserver\raddb directory. This directory tree may bedifferent if the application was installed in a directory other than the default installation directory.

To confirm that the RADIUS Tunnel Attributes are properly defined in the RADIUS dictionary file, perform thefollowing steps:

Step 1: Using a text editor such as Wordpad, navigate to the location of the RADIUS dictionary file and open thedictionary file.

Step 2: Perform a search and locate the words “Tunnel-Type”, “Tunnel-Medium-Type”, and “Tunnel-Private-Group-Id” in the dictionary file. Verify that the three RADIUS Tunnel Attributes are defined in the ATTRIBUTE section of the dictionary as displayed below. Notice the “tag-int” and “tag-str” requirements that require our

sample installation to precede each tunnel attribute value with the “:1:” tag.

ATTRI BUTE Logi n- LAT- Por t 63 st r i ng ( 1, 0, 0) ATTRIBUTE Tunnel-Type 64 tag-int (*, 0, 0)

ATTRIBUTE Tunnel-Medium-Type 65 tag-int (*, 0, 0)

ATTRI BUTE Tunnel - Cl i ent - Endpoi nt 66 t ag- st r ( *, 0, 0): : :: : :

ATTRI BUTE Conf i gur at i on- Token 78 st r i ng ( 0, 0, 0)ATTRI BUTE EAP- Message 79 st r i ng ( *, *, *)# RFC 2869 RADI US Ext ensi ons - - Si gnature i s deprecat ed

ATTRI BUTE Message- Authent i cat or 80 st r i ng ( 1, 1, 1, NOLOG)ATTRI BUTE Si gnatur e 80 st r i ng ( 1, 1, 1)

ATTRIBUTE Tunnel-Private-Group-Id 81 tag-str (*, 0, 0)

ATTRI BUTE Tunnel - Assi gnment - I d 82 t ag- st r ( *, 0, 0)ATTRI BUTE Tunnel - Pref er ence 83 t ag- i nt ( *, 0, 0)







WITH LDAP

Step 3: Continue searching for the words “Tunnel-Type” and “Tunnel-Medium-Type” until the VALUE section ofthe dictionary is displayed. Verify that the Tunnel-Type and Tunnel-Medium-Type attribute values aredefined in the VALUE section. If they are missing, add them into the dictionary file using the string and decimal

values listed below:

Attribute String Value Decimal ValueTunnel-Type VLAN 13Tunnel-Medium-Type IEEE-802 6

The String Value specified in the dictionary file must match the object class attributes for the aaaReply objectused for each user’s LDAP record.

EXAMPLE:

# Tunnel Type Val ues

VALUE Tunnel - Type PPTP 1VALUE Tunnel - Type L2F 2VALUE Tunnel - Type L2TP 3VALUE Tunnel - Type ATMP 4VALUE Tunnel - Type VTP 5VALUE Tunnel - Type AH 6VALUE Tunnel - Type I P- I P- Encap 7VALUE Tunnel - Type MI N- I P- I P 8VALUE Tunnel - Type ESP 9VALUE Tunnel - Type GRE 10VALUE Tunnel - Type DVS 11VALUE Tunnel - Type I P- I P 12

VALUE Tunnel-Type VLAN 13

# Tunnel Medi umType Val ues

VALUE Tunnel - Medi um- Type I Pv4 1VALUE Tunnel - Medi um- Type I Pv6 2VALUE Tunnel - Medi um- Type NSAP 3VALUE Tunnel - Medi um- Type HDLC 4VALUE Tunnel - Medi um- Type BBN- 1822 5

VALUE Tunnel-Medium-Type IEEE-802 6

VALUE Tunnel - Medi um- Type E- 163 7VALUE Tunnel - Medi um- Type E- 164 8VALUE Tunnel - Medi um- Type F- 69 9VALUE Tunnel - Medi um- Type X- 121 10VALUE Tunnel - Medi um- Type I PX 11

VALUE Tunnel - Medi um- Type Appl et al k 12VALUE Tunnel - Medi um- Type Decnet I V 13VALUE Tunnel - Medi um- Type Banyan- Vi nes 14VALUE Tunnel - Medi um- Type E- 164- NSAP 15

Step 4: Save the dictionary file in text format without the “.txt” extension.







WITH LDAP

Creating Port-Based VLANsPort-Based VLANs must be created on each Foundry device participating in the 802.1X Dynamic VLAN Assignmenttopology. 802.1X Dynamic VLAN Assignment is only supported on port-based VLANs. This feature cannot be

used to place an 802.1X-enabled port into a Layer 3 protocol VLAN.

Step 1: Create the necessary Port-Based VLANs on each Foundry device. The VLAN IDs or names must match

the Tunnel-Pvt-Group-ID used in the Remote Access Policies created in the previous step.

To create the port-based VLAN: Syntax: vlan <vlan-id> by port

To add ports: Syntax: untagged ethernet | pos <portnum> [to <portnum> | ethernet <portnum>]

To turn on Spanning Tree Protocol: Syntax: [no] spanning-tree

EXAMPLEThis example creates a port-based VLAN with the VLAN ID of 10 and assigns an untagged uplink port E7/24 tothe VLAN. Users matching the VLAN Group ID of 10 will be automatically added to this VLAN using 802.1XDynamic VLAN Assignment.

Dept_Switch-1(config)# vlan 10 by portDept_Switch-1(config-vlan-10)# untagged eth 7/24Dept_Switch-1(config-vlan-10)# spanning-treeDept_Switch-1(config-vlan-10)# exitDept_Switch-1(config)# write memory

Step 2: Repeat Step 1 for each Port-Based VLAN that needs to be created.

Testing The Dynamic VLAN FeatureIn order to successfully test the 802.1X Dynamic VLAN Assignment feature, the following components must befully installed and configured according to the procedures outlined in this White Paper:

• Authentication Proxy Server – such as Interlink Networks Secure.XS server

• LDAP Directory – such as OpenLDAP

• LDAP user accounts must be configured with the RADIUS Tunnel schema to support the necessary Tunnel

attributes• LDAP user accounts must be configured with the correct Tunnel attribute and VLAN ID values• The Authentication Proxy Server’s dictionary must be configured to support and forward the RADIUS tunnel

attributes

• Foundry 802.1X capable device with version 07.6.03 code or later

• 802.1X compliant workstation or file server







WITH LDAP

Step 1: Using a workstation that is configured properly for 802.1X client support, connect to the Foundrydevice’s 802.1X enabled port.

Step 2. Follow the steps outlined in the section, “Testing The Client Connection” on page 17 to authenticate the

client. Use one of the LDAP user accounts that were configured with the VLAN object parameters.

Step 3. Once the client is authenticated, check the Foundry device to make sure the client’s port is added tothe proper Port-Based VLAN. Use the following CLI commands on the Foundry device to validate the VLANassignment:

Syntax: show run Displays the dynamically assigned ports in each Port-Based VLAN.

Syntax: show interface <port> Displays detailed port information showing the original Layer 2 VLAN theport belonged to before the dynamic assignment and the VLANmembership after the dynamic assignment.

EXAMPLE – Show Run CommandThis example displays the results of the “show run” command. An 802.1X client was authenticated using a validuser account on the OpenLDAP directory server that had their Tunnel-Private-Group-ID set to 5. From the “showrun” illustration, the 802.1X client is connected to port Ethernet 22. After successful authentication, port Ethernet22 is dynamically assigned to Port-Based VLAN 5 as an untagged port.

SW-telnet@FI4802-PREM#show runver 07.6.03B2T51!dot1x-enableenable ethe 20 to 29!vlan 1 name DEFAULT-VLAN by port!

vlan 10 by portuntagged ethe 1!vlan 20 by portuntagged ether 11!vlan 5 by portuntagged ethe 21untagged ethe 22







WITH LDAP

EXAMPLE – Show Interface CommandThis example shows the dynamic VLAN information for port Ethernet 22 after the automatic VLAN assignmentwas made. Note the original VLAN ID was 1 and the new dot1x-RADIUS assigned VLAN is 5.

SW-telnet@FI4802-PREM#sho int e22FastEthernet22 is up, line protocol is upHardware is FastEthernet, address is 00e0.8041.a315 (bia 00e0.8041.a315)Configured speed auto, actual 100Mbit, configured duplex fdx, actual fdx Member of L2 VLAN ID 5 (dot1x-RADIUS assigned), original L2 VLAN ID is 1, port is untagged, port state is FORWARDINGSTP configured to ON, priority is level0, flow control enabledmirror disabled, monitor disabledNot member of any active trunksNot member of any configured trunksNo port name

: : : :: : : :

NOTE: For more information on Foundry’s 802.1X Dynamic VLAN Assignment feature and new status messages,refer to the 07.6.03 Foundry Switch and Router Command Line Interface Reference and Release Notes.







WITH LDAP

Foundry Networks, Inc.Headquarters2100 Gold StreetP.O. Box 649100San Jose, CA 95164-9100

U.S. and Canada Toll-free: (888) TURBOLANDirect telephone: +1 408.586.1700

Fax: 1-408-586-1900

Email: [email protected]: http://www.foundrynet.com

Foundry Networks, BigIron, EdgeIron, FastIron, NetIron, ServerIron, and the “Iron” family of marks aretrademarks or registered trademarks of Foundry Networks, Inc. in the United States and other countries. All othertrademarks are the properties of their respective owners.

© 2003 Foundry Networks, Inc. All Rights Reserved.

wp 8021x authentication ldap

Documents