[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: the three-headed dog at the doorstep...



[Andreas B. Mundt]
> Hi all,
> 
> after some successful tests I have been thinking about how to
> proceed with the implementation of kerberos. The changes to our
> sources might not be too small and the whole setup is probably
> influenced (in a positive way). Here are some ideas and thoughts
> that are puzzling me:

Very good to hear you have success with Kerberos.  It has been on the
wishlist for a few years now, and might finally be within reach. :)

> Can we get rid of the hardwired, predefined machine management?
> Currently, when ldap is bootstrapped, there is already a long list
> of staticXX, dhcpXXX and some more entries. The IP ranges are
> predefined and machines have to be added to the correct network
> range. This complicates the administration of the ldap-tree, and to
> do that in a user-friendly way special tools are necessary
> (currently lwat).

All these entries are only for convenience and are not required for
anything.  If it is easier to drop them, we can do that already,
without switching to Kerberos first.

> Is it possible to get rid of (part of) that? Correct me if I am
> wrong: With kerberos, a machine is authenticated by an entry in its
> keytab. With that key, it identifies with the kdc. To mount the home
> directory, the user needs a valid TGT (ticket-granting-ticket) which
> is obtained during login. A "special" IP-adress might not be
> needed. So you would have to act on standard objects in ldap: users,
> groups and machines, and no lwat-magic remains. The only thing left
> (outside ldap) is to attach a principal to every ldap object needed
> for authentication (combine this with the creation of home
> directories?) and to drop keytabs on machines (combine this with the
> distribution of our certificate?).

The only reason we have static allocation of IP addresses today is for
NFS 3 exports, which uses IP addresses for access control.  If we can
use Kerberos instead for access control (which probably would require
us to replace autofs with something else), we can drop the static IP
allocation.

Which file system did you have in mind for use with Kerberos?  NFS v3
can't be used, as far as I know.  NFS v4 might work, but I know no-one
using it in production at the moment, and we do not really want to be
the first. :) AFS is an option, but can't export existing file systems
and need to export devices.

> So what do you think about that? I do not have the experience to
> oversee all implications, but as far as I can tell we can gain a
> "simpler" system, easier to set up, easier to maintain our
> configuration packages, and more flexible and straight forward
> without loss of security features. But I am not an expert in this
> field. Someone who knows the reasons for the current setup and its
> security framework should give his ok too.

I believe we should take it step by step, by first delegating password
checking to Kerberos while keeping LDAP as the database, and when this
is operational, look at replacing the current NFS v3 autofs setup with
something that uses Kerberos for authentication.  This way we have a
chance of getting someting ready for release shortly after Squeeze is
released.

Happy hacking,
-- 
Petter Reinholdtsen


Reply to: