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 -- To UNSUBSCRIBE, email to debian-edu-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100505080712.ga4...@flashgordon