Security

Hello everyone,

 

We are in the process of implementing an Aruba 6000 Controller with m3 modules and AP-105's. Most of the setup is now up and running and we are now on the issue of authenticating users. Initialy, we were hoping to have the users authenticate through LDAP. After reading many posts on the boards, I am now second guessing that notion, it seems most experts are pushing the RADIUS authentication instead of LDAP.

 

We do not have a RADIUS server in place as all authentication is done through LDAP (Active Directory - MS Server 2008 Native mode) and we were hoping not having to setup another box.

 

My question is this : What are the advantages vs disadvantages of each? RADIUS vs LDAP.

 

Thanks for your time.

Hi,

What are your requirements for authentication?  If you are using 802.1x, I would recommend RADIUS.  Easier and more flexible.  If you're just using Captive Portal, then should be able to get away with using LDAP.  LDAP has some caveats and weird issues I've ran into when deploying 802.1x so I tend to stay away from it.

I've done many implementations using Microsoft's IAS/NPS service.  It's free and can usually just be enabled on an existing server.  I recommend you use 2 servers for redundancy.  If you have any issues with implementation let me know.

-Mike

i too have plan to configure 802.1X authentication with LDAP. Would you mind to share what strange issues you encountered previously?

 

On the use of Microsoft IAS as Radius, how can it be configured to restrict connected sessions by user id/user group?

fcstang,

Check this out.

 

http://community.arubanetworks.com/t5/Authentication-and-Access/Step-by-Step-How-to-Configure-Microsoft-IAS-Radius-Server-from/m-p/14391/highlight/true#M80

 

If you have any issues with it, let us know.

 

For user groups in AD, just have to check a condition to verify user is within that group.  You can also return attributes from IAS, which can be used to placed users into specific roles once authenticated.  It's fairly simple once you do it once or twice.

 

-Mike

 

Thus,

 

If given a choice to use [A] Radius (e.g. MS IAS, OpenRadius) or [B] LDAP (e.g. OpenLDAP), which one is recommended, as below:

1. In terms of easier to roll out [A or B or ...]? ___

2. In terms of easier to manage [A or B or ...]? ___

3. In terms of easier to troubleshoot/support [A or B or ...]? ___

Why not look at Aruba's ClearPass for RADIUS auth. Let's you use LDAP as an indentity store for auth and authorization. Let's you do more for internal and personal devices versus IAS. Not free, but not expensive.

 

http://www.arubanetworks.com/products/clearpass/

 

The biggest challenge with using LDAP for dot1x authentication is that you are required to run EAP-GTC on the clients. Most Windows clients dont have a GTC capable supplicant, so you would have to find, test and load one on each device. Using RADIUS for dot1x (PEAP) authentication doesn't require anything extra since the Windows supplicant already supports it. As mnarine said, you can most likely enable IAS/NPS on one of your existing servers for RADIUS services.

I would tend to agree with the other replies you already got. Depends on what sort of users and client devices you're supporting.

 

LDAP is fine for captive portal auth purposes (I even got derivation working into Novell a long time ago!), but not so flexible or easy to leverage when running 802.1x in from clients (by way of controller EAP termination for example). You'll find it time consuming and get ready to troubleshoot.

 

Ask yourself if your client devices are under your control (i.e. does your business own them).

 

If they are, go 802.1x and install yourself an IAS or NPS server (or 2 for resilience) in your AD. It's not a difficult product to configure, and can go on a server that's already got a different primary role (as long as the RADIUS ports aren't in use). You'll need a certificate too of course for almost all EAP types.

 

If the clients aren't under your control (student devices at college etc), then LDAP or RADIUS is fine and give them a captive portal. Doing it any other way will give you a big admin overhead. If the user has to "do something" with their device (configure it), get ready for support calls. Also, don't forget to firewall the users in this scenario with the PEF-NG!

 

Good luck.

 

 

A little more technical detail for your information...

 

When you do LDAP authentication on an Aruba controller, the controller attempts to bind to the LDAP server using the user's credentials.  If the bind is successful, we interpret that as a correct set of credentials, and the user is authenticated.  This also generally means that the controller needs to get the user's password in plaintext, so that it can carry out the LDAP bind.  With captive portal, that's easy.  With 802.1X, that's not easy.  Most 802.1X supplicants are set up with PEAP-MSCHAPv2 by default.  Using this method, the controller never receives the plaintext password - only the MSCHAPv2 hash of the password.  WIthout the password, the controller can't bind to LDAP.

 

There are other ways of dealing with MSCHAPv2 hashes.  If the LDAP server stores the password as an MSCHAPv2 hash, then in theory we can bind to the database as an admin user, pull down the user's hashed password, and do a comparison.  I've never seen this work in practice outside of a lab though, and it is highly dependent on how the LDAP server stores data internally.

 

To get around this issue and still let LDAP work, Aruba produced a PEAP-GTC plug-in for the Microsoft 802.1X supplicant.  It still uses PEAP, but adds a different inner method which uses GTC (Generic Token Card).  GTC was designed for SecurID tokens and other one-time passwords, where sending the cleartext password isn't considered a security risk.  When used for username/password authentication, it does allow the controller to receive the cleartext password, and thus lets you work with LDAP successfully.  But it means rolling out client software, and that's the administrative overhead that others have commented on in this thread.

 

To cut to the chase, 802.1X was designed with RADIUS in mind.  PEAP-MSCHAPv2 fits into the natural order of how RADIUS operates.  Where LDAP is designed as a database, RADIUS naturally handles challenge/response protocols like MSCHAPv2.  So I'll offer the same advice that others have - use RADIUS and Be Happy.

Thank you all for your suggestions and the valuable information.

 

We have decided to use RADIUS for authentication, I've easily configured an NPS server and linked with the controller and I haven't looked back.

 

It works like a charm!

 

Cheers!