01-18-2012 01:00 PM
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.
01-18-2012 01:14 PM
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.
01-18-2012 01:21 PM
01-19-2012 12:51 AM
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!
01-23-2012 05:52 PM
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.
Jon Green, ACMX, CISSP
02-01-2012 07:29 AM
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!
02-12-2012 10:29 PM
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?
02-13-2012 11:25 AM - edited 02-13-2012 11:26 AM
Check this out.
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.
2 weeks ago
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 ...]? ___