On Aug 23, 8:01am, Sam Hartman wrote: } Subject: Re: UI for Kerberos accounts administration
Good evening to everyone, hope that the week is going well for everyone. > >>>>> "Lukas" == Lukas Kubin <[EMAIL PROTECTED]> writes: > > Lukas> Do the K5 enabled sites administer accounts this way? > > Many do. > > Sites like MIT and CMU have administration servers that accept > requests for account creation, update, etc from support staff and > proxy them to the administration services. > > These systems tend to be database backed, very complicated , fairly > custom, and under documented. Some of them are semi-public in that > the sources are available and the license is reasonable. If you > managed to find the sources and get it all working you could use it. > > You might take a look at http://www.hurderos.org/ I think that their > focus is somewhat different but that they may end up solving some of > the same usability problems you're looking at. Hurderos actually traces its roots back to one of those database backed, very complicated, very custom and severely under-documented systems.... :-) A lot of the thought and design that has gone into it was motivated by what it would take to provide a generically useful tool for managing a merged LDAP/Kerberos infra-structure. In a larger sense Hurderos is about the notion that everything in information delivery starts with and derives from the notion of creating secure intrinsic identities. The concept of services being a natural outgrowth of this design predicate means that things like provisioning Kerberos accounts falls out in sort of a natural fashion. Lukas if you are interested in a more graphical approach to managing Kerberos accounts I would grab the current sources and consider building on top of that. There is a lot of fairly basic infra-structure that you would find useful. Most notably a reasonably functional GUI that uses GSSAPI to create a secured context for administrative access. Just a quick final comment about handling credentials to authenticate to kadmind for managing the database. The dirty little secret about this whole business is that there is always a dirty little secret. Since the Trusted Computing Base for an enterprise is dependent on this particular dirty little secret means that managing it securely is an important isssue. The code drop after the one coming out in the next day or so should have support for encrypted keytabs in ISME (the administrative application). The initial model will involve entering the decryption key into ISME when it starts. This will allow ISME to decrypt the keytab and obtain short-lived credentials which are passed on to the Service Provisioning Layer to authenticate the administrative transaction with the KDC. This should help minimize the threat of a compromised application server leading to a compromise of the authentication database. Unlike the KDC, ISME doesn't need to be running 24x7 in order to keep a shop on the air. That lessens the need for something like a key-stash file which essentially minimizes the utility of having an encrypted authentication database. We have a file transfer primitive built into the ISME-XML protocol. Down the road the vision is to support public-key based encryption of the administrative keytabs. This would allow an organization to impose a two-factor authentication requirement for certain security sensitive operations such as changing or modifying authentication identities. > --Sam Best wishes for a productive week to everyone. }-- End of excerpt from Sam Hartman As always, GW ------------------------------------------------------------------------------ The Hurderos Project Open Identity, Service and Authorization Management http://www.hurderos.org ________________________________________________ Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
