[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Radius and ldap

On Wed, 22 Dec 1999, David Lee wrote:

> Is there not scope for doing this "from the other end"?  That is, to allow
> openldap to respond to radius requests.

Why?  The UNIX philosophy is that each application should do a few things
well, instead of doing everything in a mediocre fashion;  OpenLDAP is intended
to do LDAP, and do it well.  From an admin's perspective, there is some
comfort and convenience in having all these things rolled into a single
product, but that's why there are commercial alternatives.

> That way, it could work with any radius client, whether Open Source or
> commercial.

If the idea is merely to merge a few different products/protocols (LDAP,
RADIUS, DIAMETER, etc.) simply because it would be "useful", then where do you
stop?  Should COPS, SNMP, DMI and SLP all be thrown in too because in a
directory-enabled network, all these management/facilities protocols should be
sharing core infrastructure information from the one source/directory?

Part of the flexibility of the UNIX environment is the ability to build
solutions from different vendors and have everything work together (akin to
building with Lego blocks), rather than have a single monolithic solution that
attempts to solve everyone's problems - and ends up solving none.

> Sun's "Directory Services 3.1" LDAP (bundled with Solaris 7) takes this
> approach.

Novell's NetWare 5 also has built-in RADIUS and LDAP support;  this is
something these vendors (Sun and Novell) believe give them an "edge" in the
marketplace as some users prefer or require this kind of solution.  Sometimes
an open source solution is the most appropriate for resolving a problem,
sometimes it is not;  each solution needs to be evaluated on its own merits
for resolving each problem.

> For example:  our site uses openldap, tacacs and NIS:  if openldap
> supported tacacs (or radius) and NIS, we would strongly consider migrating
> everything to openldap, and it would also give us some benefit over and
> above that mentioned. 

The idea is to build a complete solution from interchangeable building
blocks;  for example, we currently run LDAP into NetWare 5 and have TACACS+
for remote access authentication (no NIS/NIS+ and OpenLDAP only in
experimentation).  Once OpenLDAP 2.x is released (LDAPv3 support) there is a
strong possibility of moving some applications away from NetWare/LDAP to
OpenLDAP - with little or no change to the applications (because they're still
just talking to an LDAP server).

For TACACS+, I'm looking at the FreeRADIUS project as a replacement so that
the backend is again, just another LDAP server (be it NetWare/LDAP, OpenLDAP,
Netscape, Oracle or other).  Having a separate RADIUS front-end means it can
be deployed in a number of locations for redundancy, quite apart from the
infrastructure design of replicated LDAP servers.  If you end up coding that
(separate RADIUS front-end) into OpenLDAP, then haven't you just gone back to
what we have now (separate LDAP and RADIUS projects)?

As for NIS, depending on your reliance you can start looking at something like
PADL's nss_ldap and pam_ldap modules for replacing NIS on clients, having them
all talk directly to an OpenLDAP (or other vendor's) LDAP directory.

Apart from software infrastructure, the key to making all this work is
compatible schemata - and work is being done feverishly in this area already
(for example, there already exists a schema for storing RADIUS information in
an LDAP directory).