Hi Marcus -- I'm definitely interested in your "uniqname" implementation. I'm not sure if the portability issue is a factor, but just as background info I'm running MIT Kerberos 1.2.2 and openldap 2.0.23, RedHat7.2. If you would like to share this software, I'll be glad to do a little testing for you.
Thanks -- John -----Original Message----- From: Marcus Watts [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 22, 2002 10:18 AM To: Kerberos (E-mail) Subject: Re: LDAP/Kerberos user management "John Green" <[EMAIL PROTECTED]> writes: > Hi, I am trying to find a method for a principal automatically being created > in a Kerberos database while at the same time adding a corresponding entry > to an LDAP database. Has anyone heard of or is anyone using something like > this? I have found some utilities for sale on the web (some might even > work), just looking for alternatives. I am trying to automate the creation > of username/password/ldap_entry/Kerberos_principal/customer_web_site, which > the customer will be able to accomplish without IT intervention from a > common web site. The usual solution for this would be to write some sort of special purpose logic to do it. Some ldap server implementations have back end hooks that could be used to push directory information out to other servers. That would work for for populating principals. That won't be directly helpful for setting the password though. There are a number of different kerberos implementations out there, each of which has their own special unique administrative interface. The interfaces are different enough that it would be hard to write portable stuff to run on top of them. Perhaps even more critically, generally every organization thinks they have their own unique needs for how entries are created, maintained, and deleted, and most organizations are small enough that various ad hoc methods suffice. Here at the University of Michigan, we have long used "uniqname" to handle many of these problems. Uniqname is a central server that interfaces to kerberos, afs, and several external directories including ldap. Uniqname in turn distributes administrative rights - a uniqname administrator works on behalf of some group (typically a department) and has the right to create uniqnames on behalf of that group, and to reset passwords for for that group, but not for others. A uniqname is per-individual not per-department, people who have multiple affiliations can have a lifetime or "interest" set by more than one group, and the individual can designate which groups they trust to reset their password. By default, a department that sets a lifetime has no rights, so a rogue department can't just set a lifetime on every uniqname on campus and steal everyone's identity. Uniqname was originally designed to solve the distributed administration problem, but today, we also use it to deal with propagating directory information out to several services, including an ldap directory. Uniqname does not directly solve the "handing new accounts out to people" problem, but it's obviously involved in the process and, by virtue of being a real-time on-demand client-server application, it definitely facilitates doing this kind of stuff. Having a uniqname is only one part of what people traditionally think of as a "computer account". There are generally also authorization issues (and we're working hard to train people to realize that having a uniqname does not in itself mean "a current staff/student"), funding issues (do they have the right to use national dial-up services?), an email mailbox, and other resource issues (do they get an AFS home directory?). Actually, having an ldap directory entry is itself an optional resource issue at UM, although in many ways it would have been easier to define this as as something one has as long as one has a uniqname (complicated internal politics, don't ask.) We've actually had a number of different "front-end" systems in place to hand out new uniqnames over the years. At one point, most uniqnames were being created by the sites monitors at the "campus computing sites" using a special macintosh based client program. At another point, many uniqnames were created using a batch based process and centrally supplied data. Today, many uniqnames are being created using a self-serve web server based front end (ie, upon admission, the student pulls up a web page, supplies the appropriate initial identification and authentication information, selects a password, gets a uniqname, and receives computing services, including filespace, email, and the ability to sign up for courses.) I imagine you'll find virtually any large kerberos site has at least some of the same problems, and very likely has tools that automate some portion of account creation or management. It is probably much more common to have this run by staff as part of some batch process, rather than run as an interactive real-time on-demand client/server type application, though I'd love to hear of exceptions. In general, I think people have a very strong sense of "not invented here" about this sort of stuff. There are some very interesting genuine fundemental security issues here, so, I don't know how much actual code sharing you'll find. We made uniqname available for a number of years, but never found much excitement elsewhere over other places actually using it. We could certainly make what we're running today available, but it would be pretty much on an "as is, has lots of crufty customization in it" basis, because based on external demand we've found no reason to worry about portability. -Marcus Watts UM ITCS Umich Systems Group ________________________________________________ Kerberos mailing list [EMAIL PROTECTED] http://mailman.mit.edu/mailman/listinfo/kerberos ________________________________________________ Kerberos mailing list [EMAIL PROTECTED] http://mailman.mit.edu/mailman/listinfo/kerberos
