The Deep End | Paul Venezia » June 2007

June 08, 2007 | Comments: (0)

Making APC network cards play nice with Active Directory

TAGS: Gear, Networks, Systems

Since I'm flush with APC gear at the moment, I've been working with the network management devices (obviously, since I wrote Cacti and Nagios plugins for most of them). One of the features of most of the hardware is the ability to use local or RADIUS authentication. Obviously, with a large number of devices, using centralized authentication is not just a good idea, it's the only way to fly. Unfortunately, none of the NMCs have straight-up LDAP auth, but they will do RADIUS. Thus, using Microsoft's IAS (Internet Authentication Service) -- their interpretation of a RADIUS server, it's possible to do auth to AD via RADIUS though it's not exactly straightfoward.

APC has a knowledgebase document that describes a RADIUS implementation using FreeRADIUS. I'm a big FreeRADIUS fan, having used it in countless UNIX and dialup scenarios. However, it won't authenticate to AD without some serious gyrations, and it's simpler to use IAS. In order to use IAS, however, custom attributes need to be defined, otherwise logins may work but the admin bit will not be set and administration of the devices will be impossible. Here's the remedy.

Install IAS on a Windows server and register it with AD. Then, define a client. The client should be configured with any friendly name, and the IP of the NMC card in the APC device. Set the vendor to RADIUS Standard, and define the shared secret you'll be using. Next, define a new Remote Access Policy. Add some conditions, such as Windows-Groups matches "DOMAIN\Domain Admins" AND Client-IP-Address matches "172.16.1.*", which would cause this policy to only grant access if the user account is in the Domain Admins group, and the client IP falls within the 172.16.1 network. It's a good idea to restrict access in this way, since IAS RADIUS policies stop on the first match -- if you have multiple policies, you want them to be specific to their task.

Once this is done, some custom attributes have to be defined to grant admin privs to the user logging into the APC gear. Click Edit Profile with in the policy properties page. Click the Advanced tab, and Add an attribute. Select Vendor-Specific, and then click Add. Click Enter Vendor Code, and enter 318 into the text field to the right. Then, click Yes, it conforms, and then click Configure Attribute. Set the Vendor Assigned Attribute Number to 1, Attribute Format to "Decimal", and the Value to 1. This specifies that the value of attribute number 1, with Vendor Code 318 should be a decimal (integer) and be set to 1. The other possible values are 2, which denotes a device login, or 3, which is a read-only login, and is the default if this attribute is not defined. Note that by defining another policy that might match on a different set of groups, and setting this value to "3" will result in those users getting read-only access to the same devices, which might be handy.

Click OK a few times to get back to the Profile settings dialog, and select Authentication. make sure CHAP and PAP are selected, then click Apply and OK. Make sure that "Grant remote access permission" is selected, and click OK again. At this point, the server should be configured properly for the one RADIUS client originally specified. I usually stop and restart the IAS server at this point, since I've seen it act oddly when this isn't done.

Now, log into the APC device and configure RADIUS authentication. This is usually found on the Administration tab, under Security/Remote Users. Note that this has been tested with APC app module v3.3.1, and aos 3.3.4. If you haven't updated to this revision of the firmware on your devices, it's well worth the time to do so before continuing. Prior revisions may not even support RADIUS auth, for instance.

Fill in the server IP address and shared secret, then test the authentication. Assuming it works, set the authentication selection to "RADIUS, then Local Authentication", log out and then log back in with an account that matches the Remote Access policy defined on the IAS server. You should be in like Flynn.

I've run into some issues with using Network PowerChute with RADIUS authentication -- namely, the Network PowerChute service will not properly authenticate to a UPS NMC card that's configured for RADIUS auth, even with valid RADIUS credentials. I'm working with APC on a solution to that issue now, but I've tested this configuration with APC managed rack PDUs and air units without issue.

Posted by Paul Venezia on June 8, 2007 12:33 PM

June 01, 2007 | Comments: (0)

Introducing ASAP - Automated Switchport Access Provisioning

TAGS: ./configure && make && make install, Networks, Systems

...or something like that.

ASAP is a PHP/Perl application that automates switchport VLAN assignments for Cisco switches.

The good stuff:

o- Web and telnet interface
o- Can handle multiple switches across multiple sites
o- All switch interaction is via SNMP
o- Forces selected switchport down/up, causing Windows systems to automatically release/renew a DHCP lease
o- Prunes the ARP table following a VLAN modification
o- Can prevent certain subnets and IP addresses from being modified
o- Can be easily used by end-users
o- Admin interface provides instant system location by hostname, IP or MAC address
o- LDAP authentication for admin interface
o- MySQL logging
o- Basic reporting tools
o- Has been tested on CatOS and IOS with Cisco 6500-series and 3500-series switches

The bad stuff:

o- Rudimentary reporting needs work
o- Unsure of scalability. Sites with dozens of switches may require code tweaks
o- Hasn't been tested on several switch classes
o- Configuration could be more straightforward

Overview:

Once a network has been built and is fully operational, the vast majority of configuration tasks are simple VLAN assignments. Usually, these assignments happen only once, when a workstation is first introduced into the network, but in lab environments, VLAN assignments can occur constantly. ASAP was designed to remove the burden of system switchport location and VLAN modification from IT, and allow general users to easily perform these changes. Alternatively, ASAP can be configured to only allow admin access, and given a MAC address, IP address, or hostname, a specific system's current switchport can be located and modified without telnetting to a switch, and with an audit trail.

I originally wrote this right before I moved two large sites from one building to another. Each site had over 800 switchports and I was lazy enough to not want to deal with VLAN assignments. I wrote the ASAP Web and telnet applications, and placed every switchport into a VLAN with ACLs preventing access to any internal resources other than the Linux server running the apps, a dhcpd and a wildcard DNS server. Thus, whenever a client is plugged into an unknown switchport, they're given an IP in the "deadzone" range, and any Web site they try to visit brings up the ASAP app. They can then select the appropriate VLAN for their system, and 45 seconds later, they're fully up and running, without rebooting. *nix systems that don't run a GUI interface can also do their own VLAN assignments via the telnet application. Telnetting to the IP/hostname of the ASAP server brings up a CLI version of the Web application.

Both apps are autonomous, and can be configured independently. This permits greater modularity as well as security, since it's likely that the Web app will be used in a general corporate setting, where the telnet app will probably be used more in a lab setting. Both the Web and telnet apps log to a common MySQL database.

The apps work by determining the IP address of the connecting client, then polling each switch in turn until the IP, MAC address, switch, and switchport information is determined. Then, if the IP doesn't match a denysubnets definition, and all necessary info has been gathered, the user can select from a list of VLANs, and the app will change that specific port to the new VLAN, disable and re-enable the port (Web app only), and remove the original ARP entry from the router. With most browsers, the user will be sent to a "Please wait..." page that will refresh after 45 seconds showing that all is well. In the background, the switchport has been changed to the right VLAN, and the port disable/enable action forces Windows and Mac systems to release/renew their DHCP lease. This forces the system into the correct VLAN without requiring any user interaction or reboots. Note that the telnet app does not perform the disable/enable action though it could certainly be coded to do so.

To date, this code has been used by several hundred people to change several hundred switchports, but needs testing in lots of other settings. There are probably bugs that will be triggered by older IOS/CatOS revisions, among other things.

Configuration:

Configuration is relatively manual for now. Read through the asapd.pl and index.php files to configure the application. The most important bits are obviously the switch IP/SNMP settings, denysubnet definitions, and other site information. Note that you'll have to manually pull the VLAN index numbers from your switches. Info on how to do this is in the script comments. The included asap.sql file should be imported into a new database and general access granted to a username/pass pair matching that found in the db.inc file and the asapd.pl file via mysql -u root -p < ./asap.sql and an accompanying grant all privileges on asap.* to asap@localhost identified by 'passwd'. The help.html file can be modified to show whatever help info you wish on the main app page. login.php needs to be modified with the appropriate LDAP/AD configuration matching your site. It's currently built for non-anonymous binding to a normal Windows 2003 AD server.

So there's a bit of work to do to configure the app, but if you're at all familiar with Perl, PHP, and MySQL, it shouldn't take more than a few minutes.

Troubleshooting:

There are no debugging facilities to speak of. Since real men debug with print statements, that's what you'll find. Enjoy.

If there's enough interest in this tool, I'll put more time into tightening up the configuration and reporting, and work on any bugs that might get dug up. Either way, if you're using ASAP in your network, I'd love to hear about it. You can find the code linked below.

Download asap-0.0.1.tgz

Posted by Paul Venezia on June 1, 2007 02:44 PM