the three-headed dog at the doorstep...
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:
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).
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?).
So far I tried to implement kerberos in parallel to the existing
setup, but I have the impression this complicates things a lot. So
currently I suggest to start implementing regardless of the existing
stuff (and really break it), and concentrate with all manpower getting
things to work with kerberos for a week or so. If it works out, we
have a superb system without the cruft of the past. If not, it is easily
possible to revert all changes because they will have happened in a
clearly defined time frame.
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.
Regards,
Andi
Reply to: