Blog Entry

(View Disclaimer)

A few years back, we implemented a FreeRadius installation on an OES-Linux server. While originally it was intended for 802.1x wired authentication, it eventually morphed into the primary authentication system for our Cisco Wireless network deployment. It has been working reasonably well, despite the fact that I was brand new to Radius, and kind of just kludged it together. For details on how to setup FreeRadius to use eDirectory for authentication, you can check out the following Novell document:

http://freeradius.org/doc/radiusadmin.pdf

That said, SLES 10 apparently ships with an eDirectory integrated version of FreeRadius that I am going to have to check out sooner or later. But I am still working with OES-Linux on SLES 9, FreeRadius 1.0.5 and eDirectory 8.7.3. That is the environment this article targets.

We recently added some wireless handheld units at one of our locations, and our IT Security Manager wanted to have the units use a system specific account that would only be able to authenticate to the wireless network from the handheld units. While it is arguable as to how much additional security Mac Address authentication provides, it is an extra layer of protection against casual access. Of course, it fell to me as our Freeradius "expert" to implement the solution.

There isn't a lot of documentation out there about how to get this working. I spent a lot of time reading Radius debug logs and lived on Google for a couple of days. Eventually I noted that the wireless request passes the Mac Address of the authenticating device in the Calling-Station-Id field. I used the Radius plug-in in iManager 2.6 to find the same field for a user (under the Check Items tab). I worked through my radiusd.conf file and determined I needed to enable the checkval{} section, which is pre-configured to compare the Calling-Station-Id field. I enabled checkval, plugged in my laptop's Mac Address in eDirectory and, voila! It worked.

Sort of.

It worked for my Windows 7 laptop. But not for other laptops. After more debugging, I discovered that some clients authenticate initially as "anonymous." We use eap/peap for our wireless authentication, and the correct user information was being passed through in the encrypted tunnel. But that wasn't getting passed to the checkval authentication module. I added a couple of lines to the peap{} section in eap.conf:

copy_request_to_tunnel = yes
use_tunneled_reply = yes

Restarted radiusd, and behold it all worked.

Now, the only problem was that the Calling-Station-Id field in eDirectory is a single-valued field. And, of course, we wanted to specify multiple Mac Addresses. Sooo, back to the old drawing board.

Figured out that the actual eDirectory value is radiusCallingStationId (catchy, eh?), which is an attribute of the radiusprofile Aux class. From the Radius side, the ldap.attr file maps Calling-Station-Id in Radius to the radiusCallingStationId attribute in eDirectory. So I took the easy path (I think). Created a new multi-valued attribute called radiusCallingStationID-Multiple in the radiusprofile class, changed the ldap.attr on the Radius server to map to the new attribute, and threw a couple of Mac Address entries into the new attribute under my user object (use the Modify Object task in iManager to add new user attributes under the Other tab). And it worked. Nothing else required.

Of course, all this took me between 2 and 3 days to figure out. But that's what IT is all about, isn't it?

The final item was to create an iManager task to expose this new attribute to our Helpdesk staff. I had previously created a task to enable or disable a user's ability to authenticate wirelessly, so it was a simple item to add the new attribute to that task using the iManager Plug-in Studio.

So, there you have it. Multi-valued Mac Address authentication via eDirectory and FreeRadius. Hope this helps save someone some time.

Disclaimer: As with everything else at Cool Solutions, this content is definitely not supported by Novell (so don't even think of calling Support if you try something and it blows up).

It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.