1

The following site discusses how to setup FreeRADIUS to authenticate against an LDAP backend (it goes through a tutorial showing how to expose NT hashed passwords in FreeIPA so that FreeRADIUS can read them).

https://firstyear.id.au/blog/html/2016/01/13/FreeRADIUS:_Using_mschapv2_with_freeipa.html

It also discourages the use of Kerberos key tabs to connect FreeRADIUS to IPA because when using e.g., PAP authentication,

"FreeRADIUS can either read the NTHash and do a comparison (as above),
or it can directly bind to the LDAP server. This means in the direct
bind case, that the transport may not be encrypted due to the keytab."

On the flip side, various FreeRADIUS guides discourage the use of LDAP (e.g., see comments for the default inner-tunnel site, which states: 

    #  We do NOT recommend using this.  LDAP servers are databases.
    #  They are NOT authentication servers.  FreeRADIUS is an
    #  authentication server, and knows what to do with authentication.
    #  LDAP servers do not.

What is the rationale behind the above statement, other than a generic disclaimer?

Can someone please explain, from a security standpoint, the pro's and con's of one approach vs. the other?

I've successfully setup using an LDAP backend (no KRB) and I'm using PEAP for WiFi authentication. I'd like to better understand the security tradeoffs for this scenario.

user3814483
  • 183
  • 9

2 Answers2

3

For FreeRADIUS

The comment is there as a generic disclaimer and to address a deficiency in FreeRADIUS.

In the majority of cases you don't know what the user's DN is to perform the bind. So first, you need to bind as an anonymous user, or with a set of privileged credentials to perform that search and find the DN.

FreeRADIUS doesn't maintain separate connection pools for different purposes, so the connection must be rebound as the authenticating user.

This means in order to authenticate a user in LDAP you end up performing three operations:

  1. Bind as a privileged/anonymous user.
  2. Search for the User's DN.
  3. Bind as the user.

If the latency is high between the LDAP server and the RADIUS server this can severely limit throughput (in terms of auth/s) as FreeRADIUS in versions <= v3.0.x implements synchronous I/O.

There's absolutely no good reason not to use bind operations to authenticate users, especially where the LDAP server is using a specialised backend authentication plugin to perform the authentication. It doesn't matter what LDAP was designed for. The RADIUS protocol certainly wasn't designed for international roaming confederations and tunnelling TLS in multi-layered authentication schemes, yet it fills those roles reasonably well.

For IPA

The document you linked is confusing. It seems to be talking about using a service account to bind via Kerberos (GSSAPI) to the LDAP server, and because of deficiencies in 389DS, GSSAPI can't be combined with StartTLS or LDAPS, which means when the user's credentials would be submitted in the clear during that second bind operation.

Or it could be saying that because you can't use GSSAPI with StartTLS or LDAPS with 389DS, then the credentials would be submitted in the clear if you used Kerberos to perform the user binding operation.

In either case, I'm fairly sure this is a limitation in 389DS only, and that the majority of other LDAP servers would support GSSAPI over TLS encrypted LDAP connections.

Whatever the case, you should NEVER submit or retrieve credentials to an LDAP directory without using StartTLS or LDAPS as the article says:

Today the only secure, guaranteed way to protect your accounts is TLS. You should use LDAPS, and this guarantees all communication will be secure. It’s simpler, faster, and better.

If communication with the directory server is in the clear, then an attacker could easily snoop on either the plaintext password being submitted to the directory server, or the NTPassword coming back. The NTPassword is just the 16bit little endian encoding of the password, hashed with MD4, it's pretty much as good as plaintext.

Arran Cudbard-Bell
  • 1,514
  • 1
  • 9
  • 18
0

The comment:

#  We do NOT recommend using this.  LDAP servers are databases.
#  They are NOT authentication servers.  FreeRADIUS is an
#  authentication server, and knows what to do with authentication.
#  LDAP servers do not.

is in the context where LDAP server would be used for authentication and not as a database. This basically means radius server would try to authenticate to LDAP server using supplied credentials. And they rightfully warn you this is not the purpose LDAP was designed for.

Now, if you use LDAP as a database, which IS the case is other places, there is no problem with that.

Tomek
  • 2,950
  • 1
  • 15
  • 9