Tag Archives: ZoneDirector

Oct 10 2012
16 Comments
Microsoft, Network Administration, Ruckus, Systems Administration

How to Use Microsoft NPS for Wireless Authentication with a Ruckus ZoneDirector

I’ve already discussed using a FreeRADIUS server for wireless authentication, so now I’m going to address using Microsoft NPS, Microsoft’s implementation of RADIUS. The main reason to do this would be Active Directory integration, but other organizations may have other reasons. NPS is bundled with all versions of Windows Server starting with Server 2008. Prior to 2008, Windows Server used IAS, which may or may not conform to these directions.

The compony I work for sells IT support for commercial customers in addition to the Internet services we sell. One of our customers wanted wireless services for its branch offices with three distinct requirements:

  • Corporate-owned laptops should be able to access corporate data
  • Employees should be able to connect their own devices to the Internet, but not to access corporate data
  • Guests should be able to connect to the Internet, but with limited speeds, limited available ports, and must be forced to agree to an acceptable use policy

I’m going to address solutions to the first two requirements here, and the third will be the subject of a future post.

To meet the first requirement, we decided to use an SSID that connected to the existing data vlan for the office. This would allow traffic through the ASA to corporate data. The first security measure we considered was MAC address filtering. The problem with MAC address filtering is that it is easily spoofed. Also, it would too long to roll out, as we would have to develop a mechanism for self registration to avoid having to maintain a list of MAC addresses.

Instead, we decided to add the laptops’ computer accounts in Active Directory to a group and authenticate against that group using WPA2 Enterprise and NPS. This would prevent MAC address filtering, prevent access from corporate-owned laptops that have been reinstalled by someone other than IT, and would mean that a list of allowed devices would be more or less automatically maintained.

The second requirement had a similar solution: WPA2 Enterprise authenticating against the Domain Users group in NPS. This SSID would connect to a guest VLAN allowing access to the Internet and no other resources.

This is how we configured our Ruckus ZoneDirector to meet these requirements.

Note: We were not able to get this to work while also using NPS to authenticate for admin logins on the web interface. To get around this, we used a second NPS server for wireless authentication.

Configure NPS to Allow Wireless Access

Since the ZoneDirector does all of the communication with the NPS server, it is the only device that needs to be added as a RADIUS client in NPS. To do this, RDP into the NPS server.

  • Start -> All Programs -> Administrative Tools -> Network Policy Server
    • Expand RADIUS Clients and Servers
    • Right-click RADIUS clients
    • New RADIUS Client
      • Enable this RADIUS client = checked
      • Friendly name = ZoneDirector
      • Address = <ZD IP>
      • Vendor name = RADIUS Standard
      • Click the radio button next to Manual
      • Shared secret = <secret>
      • OK

While still in NPS, create the Connection Request Policies. First, a policy for the ZoneDirector itself:

  • Expand Policies
  • Right-click Connection Request Policies
  • New
    • Overview
      • Policy name = CR-ZoneDirector
      • Policy enabled = checked
      • Type of network access server = Unspecified
    • Conditions
      • Add
      • NAS Port Type
      • Wireless – IEEE 802.11
      • Add
      • Client Friendly Name = Zone*
    • OK

Next, a policy for the Corporate SSID.

  • Expand Policies
  • Right-click Connection Request Policies
  • New
    • Overview
      • Policy name = CR-Corp
      • Policy enabled = checked
      • Type of network access server = Unspecified
    • Conditions
      • Add
      • NAS Port Type
      • Wireless – IEEE 802.11
    • OK

Finally, a policy for the BYOD SSID.

  • Expand Policies
  • Right-click Connection Request Policies
  • New
    • Policy name = CR-BYOD
    • Policy enabled = checked
    • Type of network access server = Unspecified
    • Conditions
    • Add
      • NAS Port Type
      • Wireless – IEEE 802.11
    • OK

Now, the Network Policies need to be created. This is the most involved and probably the most confusing part, as it requires vendor-specific options. Still in NPS, create the Corporate SSID Network Policy:

  • Expand Policies
  • Right-click Network Policies
  • New
  • Overview
    • Policy name = NP-Corp
    • Policy enabled = checked
    • Access Permission = Grant access, Ignore user account dial-in properties.
    • Type of network access server = Unspecified
  • Conditions
    • Add
    • Machine Groups
    • Add Groups
    • Domain Computers
    • Add
    • NAS Port Type
    • Wireless – IEEE 802.11 OR Wireless – Other
    • OK
  • Settings
    • Standard
      • Add
      • Framed-Protocol
      • Commonly used for Dial-up or VPN = PPP
      • OK
      • Add
      • Service-Type
      • Commonly used for Dial-Up or VPN = Framed
      • OK
    • Vendor Specific
      • Add
      • Enter Vendor Code = 25053
      • Yes. It conforms.
      • Configure Attribute
        • Vendor-assigned attribute number = 1
        • Attribute format = String
        • Attribute value = Corp
        • OK
      • OK
    • OK

Next, create the Network Policy for the BYOD SSID:

  • Expand Policies
  • Right-click Network Policies
  • New
  • Overview
    • Policy name = NP-BYOD
    • Policy enabled = checked
    • Access Permission = Grant access, Ignore user account dial-in properties.
    • Type of network access server = Unspecified
  • Conditions
    • Add
    • User Groups
    • Add Groups
    • Domain Users
    • Add
    • NAS Port Type
    • Wireless – IEEE 802.11 OR Wireless – Other
    • OK
  • Settings
    • Standard
      • Add
      • Framed-Protocol
      • Commonly used for Dial-up or VPN = PPP
      • OK
      • Add
      • Service-Type
      • Commonly used for Dial-Up or VPN = Framed
      • OK
    • Vendor Specific
      • Add
      • Enter Vendor Code = 25053
      • Yes. It conforms.
      • Configure Attribute
        • Vendor-assigned attribute number = 1
        • Attribute format = String
        • Attribute value = BYOD
        • OK
      • OK
    • OK

NOTE: I use Domain Computers and Domain Users as the Active Directory groups to authenticate against as examples, but in the real world, I was more granular in which users and devices I allowed through.

Configure ZoneDirector

Now that NPS is all set up, it’s time to get the ZoneDirector ready to use the new policies. First, the NPS server needs to be added as a RADIUS server:

  • Configure -> AAA Servers
    • Create New
      • Name = NPS.radius
      • Type = RADIUS
      • Auth Method = PAP
      • IP Address = <NPS IP address>
      • Port = 1812
      • Shared Secret = <secret>
      • OK
    • Create New
      • Name = NPS.radiusacct
      • Type = RADIUS Accounting
      • IP Address = <NPS IP address>
      • Port = 1813
      • Shared Secret = <secret>
      • OK

Test the server using the form at the bottom of the page. A success message should show up and assign the user the role of Default. This is normal. We still need to configure roles to use the Corp or BYOD tags that the Network Policy hands back with the Access-Accept:

  • Configure -> Roles
    • Create New
      • Name = Corp
      • Description = AD Machine authentication for Corp
      • Group Attributes = Corp
      • Allow All WLANs = Specify WLAN access
      • WLANs = <name of corporate WLAN>
      • OK
  • Configure -> Roles
    • Create New
      • Name = BYOD
      • Description = AD User authentication for BYOD access
      • Group Attributes = BYOD
      • Allow All WLANs = Specify WLAN access
      • WLANs = <name of BYOD WLAN>
      • OK

Once again, try a user on the test form on the AAA server. Assuming the user is a member of Domain Users (or whatever group was used for the BYOD Network Policy), it should now be assigned a role of BYOD. Now on to configuring the WLANs:

  • Configure -> WLANs
    • Create New
      • Name = Corporate Devices (Call this whatever you want)
      • Type = Standard Usage
      • Authentication Method = 802.1x/EAP
      • Encryption Method = WPA2
      • Encryption Algorithm = AES
      • Authentication Server = NPS.radius
      • Advanced Options
      • Accounting Server = NPS.radiusacct
    • Create New
      • Name = Employee Devices (Again, call this whatever you want)
      • Type = Standard Usage
      • Authentication Method = 802.1x/EAP
      • Encryption Method = WPA2
      • Encryption Algorithm = AES
      • Authentication Server = NPS.radius
      • Advanced Options
      • Accounting Server = NPS.radiusacct
      • Attach VLAN tag = <BYOD VLAN ID> (make sure the box next to attach is checked)

NOTE: All other WLAN settings can be set according to your desires and/or business needs.

That’s it. Just make sure routing is set up for the BYOD VLAN, and you should be in business.

Tagged , , , ,
Oct 06 2012
7 Comments
Linux, Ruckus

How to Use FreeRADIUS for Wireless Authentication with a ZoneDirector

RADIUS is a powerful protocol, which, when paired with the ZoneDirector’s ability to assign roles to users, can provide for a lot of flexibility in terms of which SSIDs a user can connect to, whether the user can log into an admin session on the ZD, and privilege level on admin sessions. There are many different implementations of RADIUS, but this is going to focus specifically on FreeRADIUS running on Ubuntu Server 12.04 LTS.

First off, install FreeRADIUS if that hasn’t been done yet:

sudo apt-get update && sudo apt-get install freeradius freeradius-mysql

NOTE: Installing freeradius-mysql will install a MySQL server on your machine. If you are running a MySQL server elsewhere, you will probably want to use it instead. In this case, you will want to manually install the freeradius-mysql package. It is possible to install without the dependencies (i.e. MySQL) using aptitude or apt-get, but it will need to be watched during updates to make sure dependencies don’t install themselves.

Next perform the basic FreeRADIUS configuration. In the text editor of your choice open /etc/freeradius/sites-available/default and make sure that the following sections are commented/uncommented as necessary:

authorise {
preprocess
#auth_log
#chap
#mschap
#digest
#wimax
#IPASS
#suffix
#ntdomain
eap
#unix
#files
sql
#etc_smbpasswd
#ldap
#daily
#checkval
experation
logintime
pap
#Autz-Type Status-Server
}

authenticate {
Auth-Type PAP
#Auth-Type CHAP
Auth-Type MS-CHAP
#digest
#pam
#unix
#Auth-Type LDAP
eap
#Auth-Type eap
}

preacct {
preprocess
#update request
acct_unique
#IPASS
suffix
#ntdomain
files
}

accounting {
detail
#daily
unix
radutmp
#sradutmp
#main_pool
sql
#if (noop) …
#sql_log
#pgsql-voip
exec
#Acct-Type Status-Server
}

session {
radutmp
sql
}

pos-auth {
#main_pool
#reply_log
sql
#sql_log
#ldap
#exec
#wimax
#update reply {}
Post-Auth-Type REJECT
}

NOTE: This should not be copied and pasted over the current content. It is simply a guide as to which sections should or should not be commented.

The SQL settings also need to be configured in /etc/freeradius/sql.conf

sql {
#
# Set the database to one of:
#
# mysql, mssql, oracle, postgresql
#
database = “mysql”

#
# Which FreeRADIUS driver to use.
#
driver = “rlm_sql_${database}”

# Connection info:
server = “<SQL Server IP>”
port = 3306
login = “<username>” # This should be your SQL user. Default
password = “<password>” # This should be the password for your SQL user

# Database table configuration for everything except Oracle
radius_db = “<name of db>” #Default is radius
…
#Table names can be changed here, but unless there is a good reason can be left default.

FreeRADIUS is not able to pass Ruckus Roles by default, so this will have to be configured by adding a dictionary file to use vendor-specific options. Edit /usr/share/freeradius/dictionary and add the following line:

$INCLUDE dictionary.ruckus

Create a new text file called /usr/share/freeradius/dictionary.ruckus and paste in the following:

# -*- text -*-
#
# Ruckus dictionary.
#
# Enable by putting the line “$INCLUDE dictionary.ruckus” into
# the main dictionary file.
#
# Version: 1.00 08-August-2012 contributed by Eric Rochow
# $Id$
#

VENDOR Ruckus 25053

# Ruckus Extensions

BEGIN-VENDOR Ruckus

ATTRIBUTE Ruckus-Role 1 string

END-VENDOR Ruckus

The RADIUS server itself should now be ready. On to configuring SQL. Create the database radius on the MySQL server:

CREATE USER ‘radius’@’localhost’;
SET PASSWORD FOR ‘radius’@’localhost’ = PASSWORD(‘radpass’);

# The server can read any table in SQL
GRANT SELECT ON radius.* TO ‘radius’@’localhost’;

# The server can write to the accounting and post-auth logging table.
#
# i.e.
GRANT ALL on radius.radacct TO ‘radius’@’localhost’;
GRANT ALL on radius.radpostauth TO ‘radius’@’localhost’;

Create and autopopulate the tables by editing the following and copy and pasting into the mysql> prompt:

CREATE TABLE radacct (
radacctid bigint(21) NOT NULL auto_increment,
acctsessionid varchar(64) NOT NULL default ”,
acctuniqueid varchar(32) NOT NULL default ”,
username varchar(64) NOT NULL default ”,
groupname varchar(64) NOT NULL default ”,
realm varchar(64) default ”,
nasipaddress varchar(15) NOT NULL default ”,
nasportid varchar(15) default NULL,
nasporttype varchar(32) default NULL,
acctstarttime datetime NULL default NULL,
acctstoptime datetime NULL default NULL,
acctsessiontime int(12) default NULL,
acctauthentic varchar(32) default NULL,
connectinfo_start varchar(50) default NULL,
connectinfo_stop varchar(50) default NULL,
acctinputoctets bigint(20) default NULL,
acctoutputoctets bigint(20) default NULL,
calledstationid varchar(50) NOT NULL default ”,
callingstationid varchar(50) NOT NULL default ”,
acctterminatecause varchar(32) NOT NULL default ”,
servicetype varchar(32) default NULL,
framedprotocol varchar(32) default NULL,
framedipaddress varchar(15) NOT NULL default ”,
acctstartdelay int(12) default NULL,
acctstopdelay int(12) default NULL,
xascendsessionsvrkey varchar(10) default NULL,
PRIMARY KEY (radacctid),
KEY username (username),
KEY framedipaddress (framedipaddress),
KEY acctsessionid (acctsessionid),
KEY acctsessiontime (acctsessiontime),
KEY acctuniqueid (acctuniqueid),
KEY acctstarttime (acctstarttime),
KEY acctstoptime (acctstoptime),
KEY nasipaddress (nasipaddress)
) ;

#
# Table structure for table ‘radcheck’
#

CREATE TABLE radcheck (
id int(11) unsigned NOT NULL auto_increment,
username varchar(64) NOT NULL default ”,
attribute varchar(64) NOT NULL default ‘User-Password’,
op char(2) NOT NULL DEFAULT ‘:=’,
value varchar(253) NOT NULL default ”,
PRIMARY KEY (id),
KEY username (username(32))
) ;

#
# Table structure for table ‘radgroupcheck’
#

CREATE TABLE radgroupcheck (
id int(11) unsigned NOT NULL auto_increment,
groupname varchar(64) NOT NULL default ”,
attribute varchar(64) NOT NULL default ”,
op char(2) NOT NULL DEFAULT ‘:=’,
value varchar(253) NOT NULL default ”,
PRIMARY KEY (id),
KEY groupname (groupname(32))
) ;

#
# Configure the attributes for the RADIUS group ALLOW
# This can be done for as many groups as necessary and with whatever name is desired
#

INSERT INTO radgroupcheck (groupname,attribute,value)
VALUES (“ALLOW”,”Ruckus-Role”,”ALLOW”);
INSERT INTO radgroupcheck (groupname,attribute,value)
VALUES (“ALLOW”,”Auth-Type”,”PAP”);

#
# Table structure for table ‘radgroupreply’
#

CREATE TABLE radgroupreply (
id int(11) unsigned NOT NULL auto_increment,
groupname varchar(64) NOT NULL default ”,
attribute varchar(64) NOT NULL default ”,
op char(2) NOT NULL DEFAULT ‘:=’,
value varchar(253) NOT NULL default ”,
PRIMARY KEY (id),
KEY groupname (groupname(32))
) ;

#
# If the user’s group has the RADIUS attribute ALLOW, pass ALLOW to the ZD with Access-Accept
# This can be done for as many groups as necessary and with whatever name is desired
#

INSERT INTO radgroupreply (groupname,attribute,value)
VALUES (“ALLOW”,”Ruckus-Role”,”ALLOW”);

#
# Table structure for table ‘radreply’
#

CREATE TABLE radreply (
id int(11) unsigned NOT NULL auto_increment,
username varchar(64) NOT NULL default ”,
attribute varchar(64) NOT NULL default ”,
op char(2) NOT NULL DEFAULT ‘=’,
value varchar(253) NOT NULL default ”,
PRIMARY KEY (id),
KEY username (username(32))
) ;
#
# Table structure for table ‘radusergroup’
#

CREATE TABLE radusergroup (
username varchar(64) NOT NULL default ”,
groupname varchar(64) NOT NULL default ”,
priority int(11) NOT NULL default ‘1’,
KEY username (username(32))
) ;

#
# Assign a user to the RADIUS group ALLOW
# This can be done for as many groups as necessary and with whatever name is desired
#

INSERT INTO radusergroup (username,groupname)
VALUES (“<username>”,”ALLOW”);

#
# Table structure for table ‘radpostauth’
#

CREATE TABLE radpostauth (
id int(11) NOT NULL auto_increment,
username varchar(64) NOT NULL default ”,
pass varchar(64) NOT NULL default ”,
reply varchar(32) NOT NULL default ”,
authdate timestamp NOT NULL,
PRIMARY KEY (id)
) ;

#
# Table structure for table ‘nas’
#
CREATE TABLE nas (
id int(10) NOT NULL auto_increment,
nasname varchar(128) NOT NULL,
shortname varchar(32),
type varchar(30) DEFAULT ‘other’,
ports int(5),
secret varchar(60) DEFAULT ‘secret’ NOT NULL,
server varchar(64),
community varchar(50),
description varchar(200) DEFAULT ‘RADIUS Client’,
PRIMARY KEY (id),
KEY nasname (nasname)
);

CREATE TABLE `cui` (

`clientipaddress` varchar(15) NOT NULL default ”,
`callingstationid` varchar(50) NOT NULL default ”,
`username` varchar(64) NOT NULL default ”,
`cui` varchar(32) NOT NULL default ”,
`creationdate` timestamp NOT NULL default CURRENT_TIMESTAMP,
`lastaccounting` timestamp NOT NULL default ‘0000-00-00 00:00:00’,
PRIMARY KEY (`username`,`clientipaddress`,`callingstationid`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

Be sure to add the ZoneDirector to the NAS table:

INSERT INTO nas (nasname,shortname,type,secret)
VALUES (“<ZD IP address>”,”zonedirector”,”Wireless-802.11″,”<secret>”);

NOTE: Replace <secret> with a randomly generated password. Hold on to this, we’ll need it in a bit.

A user will need to be created. For now, a test user will be used. Add real users later.

INSERT INTO radcheck (username,value)
VALUES (“test”,”test1234″);

This will create the user “test” with a password “test1234”. Assign that user to the RADIUS group ALLOW:

INSERT INTO radusergroup (username,groupname)
VALUES (“test”,”ALLOW”);

SQL should be all set now. Back on the RADIUS server, start FreeRADIUS in debug mode:

freeradius -X

Time to set up the Zone Director to use this new RADIUS setup. Log into the ZoneDirector’s admin interface and go to Configure -> AAA Servers.

  • Create New
    • Name = <server name>.radius
    • Type = RADIUS
    • Auth Method = PAP
    • IP Address = <RADIUS server IP address>
    • Port = 1812
    • Shared Secret = <secret password from nas table in RADIUS>
  • Create New
    • Name = <server name>.radiusacct
    • Type = RADIUS accounting
    • IP Address = <RADIUS server IP address>
    • Port = 1812
    • Shared Secret = <secret password from nas table in RADIUS>

Test to see if the ZoneDirector can communicate properly with RADIUS. Under Test Authentication Settings, select the new RADIUS server (not accounting) from the drop-down menu. Enter the username and password of the test user and click test. A success message should show up. The role will show up as default for now. That’s OK, as we have not configured the roles yet. If a failed message shows up, take a look at the debug output on the RADIUS server. It should display that it sent an Access-Accept message back to the ZoneDirector.

Assuming everything is working properly thus far, go to Configure -> Roles.

  • Create new
    • Name = Allowed Users (this can be called anything – just make sure it’s useful)
    • Group Attributes = ALLOW (this must match the Ruckus-Role attribute exactly)
    • Specify WLAN access
    • Leave WLANs blank – the WLAN still needs to be created
    • OK

Now we need to test whether or not roles are working. Go back to Configure -> AAA Servers and run the test against the RADIUS server again. The success message should state that the user has been assigned the role of Allowed Users (assuming that’s the name the role was given).

If a new WLAN needs to be created, go to Configure -> WLANs. Here are the necessary options. Everything else can be configured as necessary:

  • Create New
    • Type = Standard Usage
    • Method = 802.1x EAP
    • Method = WPA2
    • Algorithm = AES
    • Authentication Server = <name of RADIUS server>.radius
    • Advanced Options
    • Accounting Server = <name of RADIUS server>.radiusacct

That’s it. It should be functional. Don’t forget to take the RADIUS server out of debug mode by pressing Ctrl-C and start it back up:

sudo service freeradius start

Bonus:

With the previous setup, the password will be stored in plaintext. Obviously, this is not ideal from a security standpoint. The passwords can be hashed using MD5. It is also theoretically possible to store the passwords in a salted hash format with the SMD5-Password attribute, but I have never gotten that to work. Instead of making User-Password the default attribute in the radcheck table, make it MD5-Password:

ALTER TABLE radcheck MODIFY attribute DEFAULT ‘MD5-Password’;

Existing users can have their attribute and password changed, as well:

UPDATE radcheck SET attribute=’MD5-Password’ WHERE attribute=’User-Password’;

UPDATE radcheck SET value=MD5(value) WHERE id<=<id# of the newest account that needs to be moved over>;

Enter passwords using MD5(“password”) instead of “password”:

INSERT INTO radcheck (username,value)
VALUES (“test2”,MD5(“test5678”));

This method works quite well except if RADIUS is being used for MAC Authentication Bypass for a Captive Portal. In this situation, both the username and the value (i.e. password) need to be the MAC address of a computers wireless NIC stored in plaintext  format.

Tagged , , ,