TechTalks Transcript
Getting Started with Directories
 Judith Boettcher [JB] |
 Howard Strauss [HS] |
 Frank Grewe [FG] |
 Mike LaHaye [ML] |
November 4, 1999
Audio
• Streaming
MP3
• Download
MP3 (Download
Tips)
JB: Welcome to the CREN TechTalk series for Fall of 1999, and to this session on "Getting Started with Directories." You are here because it's time to discuss the core technologies for your future campus.
This is Judith Boettcher, your CREN host for today, and I'm pleased to welcome the technology anchor for TechTalk, Howard Strauss of Princeton. Howard is a well-known Web and all-around information technology expert. Welcome again, Howard.
HS: Thank you, Judith.
I'm Howard Strauss, the technology anchor for the TechTalk series of CREN Webcasts. As technology anchor, I'll engage our guest experts in a lively technical dialogue that will answer the questions you'd like answered -- and ask those very important follow-up questions. You can ask our guest experts, Frank Grewe and Mike La Haye, your own questions by sending e-mail to expert@cren.net at any time during this Webcast. If we don't get to your questions during the Webcast, we'll provide answers in the Webcast archive later.
How would you ever find the meaning of a word if there were no dictionaries? Would you be able to use your phone effectively without phone directories? (No cheating here by calling 411 -- directory Assistance uses phone directories, too.) Would you ever be able to figure out what stores there are in a mall without the mall directory? You could just peek in each store to see what's there -- but Mall of America, for example, if you spent just five minutes in each store, it would take you over 43 hours to check them all out. A store directory speeds your shopping up quite a bit. These are just a few examples of the directories that we use every day. They give us quick access to information that identifies a word, a person, a store, a company and so forth.
Knowing how directories work from our everyday experience, however, can be a bit misleading when we try to generalize our experience to computer directories of the kind we'll discuss today. While searching the Mall of America may seem daunting, even the small university has directory needs far more complex than the world's largest shopping mall.
On campus, software directories are used primarily to identify people and systems, but they are closely linked to both authentication and authorization, which makes them an integral part of your computer security system. A directory is used not only to determine if a person has a valid ID on your campus, but also what systems that user can address, their addresses, phone numbers, job titles or for students, the courses they are taking, and usually much, much more.
Directories are accessed both by individuals who want to obtain some information about people and systems on campus, and also by virtually every computer system and application. When directories are implemented well, all of your computer systems run better and more securely. And directories hold the promise of single sign-on, heterogeneous systems that can communicate with each other and a unified security plan.
If your institution is like most colleges and universities -- even those far along on installing centralized directories -- it still has a long way to go to reach directory nirvana. And every day, there are new things to consider such as the role XML will soon play and the option to outsource all or part of your directory plan. Although LDAP (the directory protocol we'll spend most of our time discussing) stands for Lightweight Directory Access Protocol, you'll quickly discover that there is nothing lightweight about the importance of getting started with this key technology. In just a moment, we'll help you find your way through the complex maze of directory issues on today's edition of TechTalk.
Judith?
JB: Well, thank you very much, Howard. I know that I'm looking forward to our conversation today. The whole topic of directories has turned out to be much more complex, certainly, than when I first thought about it. I kept thinking about that two-inch or three-inch size directory back when I was living in Minneapolis. But at any rate, let me go ahead and --
HS: You should see it in Manhattan!
JB: A good step stool for kids? I'd like to go ahead and introduce our two experts, Howard, that you mentioned that we have with us today. One of our experts is Frank Grewe from Minnesota, and he's a manager in the Office of Information Technology. And he's been working on setting up a directory structure at Minnesota for about seven years now, I think. Frank, if I'm wrong, you can correct me.
FG: You're accurate.
JB: How many was it?
FG: Seven.
JB: It was seven, all right. Frank was with us earlier this spring and we're very pleased that he's back to continue our conversation on directories.
Our second expert is Mike La Haye, who is a manager in the Information Technology Division at the University of Michigan. Mike has experience with the Novell directory services program and is now involved in a migration of the campus LDAP service from an X.500 based service to open LDAP. And just exactly what this all means we're going to learn more about in this session.
Welcome, Frank and Michael, and thanks for being here.
HS: Okay, Michael and Frank, Judith said in a moment we're going to learn what this is all about. Maybe that's where we should start. We've all heard a lot about the need for campus directories and the role LDAP is playing, but maybe you could just start with why do we need campus directories? What do they buy us? Frank?
FG: Okay, I'll go first.
HS: Since you weren't going to choose between you, we had to do this for you.
FG: Right. We'd have been silent for quite a while.
HS: Right. If you keep quiet long enough, we'll pick one of you.
JB: That's right, you get volunteered.
FG: So the question, again, is what do campus directories do?
HS: Yeah, why bother with these campus directories? Why should we go through all this stuff? Computer systems have been around for a while. They sort of run.
FG: When we first implemented our directory at the University of Minnesota, we thought of it exclusively in terms of a way to look up somebody else's e-mail address. We have about 100,000 active e-mail addresses in our statewide system and it naturally makes sense that if you want to find somebody, you want their latest and greatest e-mail address.
HS: So you just kind of type in a name and you get their --
FG: Yeah, type in their name, get their e-mail address back and be able to do that great e-mail thing we all like to do.
However, that really was only the original use that we found for our directories. At the present time we use it for access to labs, we use it for access to Sports and Rec, we use it for access to food service. We use it for access to various Web applications.
HS: When you keep saying "access" to food services, what do you mean by access to food services?
FG: What I mean is that whether or not a particular individual is actually living in a particular dorm and can eat in that particular cafeteria?
HS: So you're using it for authorization.
FG: Authorization to have a meal at a cafeteria, that's one good example. It is being used to authorize people to get into the golf course, to get into Sports and Rec. There are labs on campus that you can only go into because you're taking particular courses. There are Web applications such as WebCT. What courses are you taking? Are you eligible to get into a particular Web course? Web pages? These are just some examples of the type of authorization that we're using our directory for today.
HS: It sounds like there was another interesting change between the time people were just looking things up to find people's e-mail addresses. And that is, with some of your authorization things it sounds like computers were actually using the directory, rather than human beings just poking around.
FG: That's right. The various computer applications are making requests against our directory to determine what the person who has authenticated is authorized to do.
HS: Michael, maybe you can address the next part of my question. Having gotten a little bit of background as to why directories might be useful, what's the significance of LDAP? Why use LDAP rather than something else?
ML: LDAP is a standard wire protocol allowing a client to transparently access a back-end directory independent of the technology supporting the data on the back end.
HS: What's that mean, what'd you just say there, Michael?
ML: That means that I'm not tied to any vendor. I'm not tied to any -- I can use standards to basically access the data out of any directory, as long as it supports the LDAP protocol.
JB: So when you're putting an application or -- pardon me, a directory -- in place and then related applications, you want to make certain that they all speak that same language of LDAP?
ML: This is correct.
HS: But what about the database? Is there a database there?
ML: There is a database. It is abstracted from the user through LDAP.
HS: But is the database an Access database, an Oracle database? Is it a relational database? Is it -- what kind of thing is it?
ML: Directories are generally not relational databases. They are special purpose databases directed at reading data, writing seldom, and processing queries as quickly as possible.
HS: Who makes these things? I mean, if I were going to build an LDAP database, where would I get the protocol from? Where would I get the database from? Where would I go out and get this stuff?
ML: The original protocol was developed at the University of Michigan. It is an Internet standard. Today there are many vendors of LDAP directories: Netscape, Novell, Microsoft is moving toward LDAP with Active Directory. Even some of the GroupWare e-mail vendors, the address books that those folks provide have been LDAP-enabled.
FG: In my case, I have an X.500 based repository for all of my data (or for all of my data in the directory) and our vendor is Control Data Systems here in Minneapolis. And we speak various protocols, LDAP being one of them.
HS: Now, because you mentioned that many, many vendors speak the LDAP protocol, given that everybody speaks the LDAP protocol, what systems do these databases reside on? Do they reside on NT systems, Unix boxes, Novell servers -- or all of them?
FG: All of the above.
ML: Yes.
HS: Does a university have a bunch of these things floating around? I mean, do the universities have one LDAP directory or do they have a dozen of them? Or are there any guidelines as to what they should have, or shouldn't?
FG: I can see it perfectly possible that a university may have multiple LDAP directories. Nonetheless, the major thing that everybody will need is a central repository that is sort of the master copy of absolutely everybody. There may, in fact, be LDAP-enabled directories that are subsets of this larger directory, that the data is fed either one direction or another from a larger master copy. But still, the need for some directory that encompasses the entire population of the university, I see, as a necessary first step.
HS: Okay, so there's one central directory. And since everybody is using the thing, it might get quite busy, so folks go off and what -- just mirror the thing?
FG: At the University of Minnesota, we have three independent copies of our directory -- complete copies of our directory -- which are located in three different geographical locations on the network and in three different physical locations so that we have 24/7 redundancy.
HS: Okay, but they all use the same technology.
FG: That's right.
HS: So they're all on the same kind of server, using all the same kind of technology. Does it matter what -- I mean, most universities have this big heterogeneous environment. Does it matter if this thing is on a Unix box or a Novell server or NT? I mean, is it equally useful?
FG: No, because that is the whole purpose of having a standard such as LDAP. The application that is using the directory only knows that it's using the LDAP protocol. It doesn't have any idea what type of system the directory actually resides on.
HS: Could we talk a little bit about where the data for the LDAP directory comes from? Frank?
FG: In our situation, the data comes from Human Resources records, it comes from student records, it comes from the Alumni Association. Those are probably our three major providers of data. But additionally to that, we have various groups that have affiliate-type individuals that they wish to have in the directory, so that we really do not have one central source for everybody in the directory. There are various organizations around the campus -- such as HR, Student Systems -- that have large percentages of the population that belong in the directory, but no one of them has everybody.
HS: Is it correct that all the data in the LDAP database is copied from somewhere else? That is, there's no source data in the LDAP directory, nothing where that's the only place where the data exists or where it originates?
ML: Well, it differs on an attribute-by-attribute basis. Much of the data we populate into our directory -- our central campus directory -- does come from administrative and student services. Information about students, faculty, staff, their phone numbers, their office addresses, what classes they're taking, etc. does come out of the institutional data repositories.
At the same time, we do give end-users the ability to modify their attributes within the directory. So if a user wants to specify their home phone number or, in fact, their favorite beverage, that's an attribute they can populate through client software.
HS: But if they change their home phone number, let's say, in LDAP --
ML: Yes.
HS: Isn't that a field that your Human Resources group keeps somewhere else?
ML: Yes.
HS: And so you need some scheme to copy that back, don't you? I mean, I change my home phone number in LDAP, I probably really mean to change my home phone number.
ML: And as you're dealing with data source issues, that's one of the largest challenges in deploying a directory.
As it stands on our campus today, we do get the data feeds out of central repositories. Users can modify that data. We, however, do not push it back to the authoritative source.
FG: In our situation, the main data sources of HR and Student Systems do have Web interfaces for self-service. So our student and staff population can go to those sources and change their home address and this type of information and then we get a feed with that update. They don't make those changes directly to the directory.
On the other hand, there are attributes that are quite specifically directory owned because there are applications that make rather instantaneous use of them. An example is the e-mail address or the password. Those types of attributes are owned by the directory, and the way our population changes them is directly through the directory interface.
HS: But are those attributes like e-mail address kept somewhere else? A central university database?
FG: What other applications use for the e-mail address is our unique network ID at umn.edu. They are not aware of the actual, real delivery address that the e-mail would go to.
For example, I may -- my address at umn.edu, I'm perfectly capable of forwarding that to an AT&T address or an MCI address or an AOL address. Where I am having my mail forwarded to is not known by the application. They would use my main address at umn.edu which points to where I want final delivery. That make sense?
HS: Yes. So in both cases, you're saying -- both Frank and Michael are saying -- that there is data in an LDAP directory that lives uniquely in the LDAP directory. It doesn't really live anywhere else.
FG: Yes. I think there is some data that does belong uniquely in the LDAP directory and doesn't belong anywhere else. There is other data that definitely belongs, or should be owned by somebody else. I don't want to be responsible for correct mailing addresses.
HS: Michael, you said that this whole idea of dealing with the institutional data sources and things was one of the real difficult issues with directories. Could you say a few more words about that? Why is that so difficult?
ML: They are owners of all the data and you have to make sure that you have the permission to use whatever data you are going to either make publicly available or use for private purposes within applications. Within the university community, registration or privacy issues -- registration data must be protected. And if you are going to publish data, you have to make sure you have the permission of the owner of that data.
HS: You brought up the issue of publishing data and it sounds like you have lots and lots of data out on your directories. I'll talk a little bit more about what you put out there, but can everybody access all of that data?
ML: There are access control lists that limit the access to individual attributes.
FG: In our situation, we have specific data items that are always public. We have other data items that the individual themselves can decide whether to have published or not. And those are basically your home address, home phone, or in the case of students, there is actually a method through Student Support Services that they can use FIRPA to completely suppress themselves.
The rest of the data that we have about people -- for example, what classes you might take or information like that -- is completely private and you must always get the data owner's permission for the application to use that.
HS: Okay, we have a couple of questions that came in, but before I get to those couple questions, I just want to finish up on this topic of institutional data. Can you give us any guidelines as to how you decide what data should be in the LDAP directory?
FG: I'll shoot with my opinion first.
HS: Okay. I heard you say "my opinion" pretty strongly there.
FG: Yeah, right.
HS: This is not your institution's opinion.
FG: Well, I think that when you hear what my opinion is, anyone who understands things will realize the political difficulty here.
HS: Okay.
FG: An LDAP directory -- when a new application comes on board, there is a large possibility that they will need an attribute or need to know something about somebody that has not previously been put in your directory. You must be in a position where you can add new attributes, new information about your people quickly.
This means that the people who are running the directory service must have the technical resources to be able to quickly and efficiently retrieve new information about your institutional individuals, okay? This doesn't mean that they have the authority to give this out to an application; that has to have the necessary sign-offs of the data owner.
What you don't want to put yourself in the position of is that every time you need a new attribute, you have to reinvent the interface between your institutional data and your directory. So where you start as to looking at what you need for your interface between your institutional data and your directory, the logical thing to assume is that you will probably need just about every piece of information that you have about somebody at some point in time in the future.
HS: So it's much more of a procedural problem than a technical problem here.
FG: Right. Don't cause yourself more technical problems by limiting the amount of data that you make available to the directory via a data feed. Make those things a policy statement as to who has authority to access data items so that it's not a technical issue every time you're adding an attribute.
JB: So Frank, are you saying that even if an easy way to get started would be to do an e-mail directory, what you don't want to do is limit yourself and design a big system just with that data?
FG: Right. A good example in our situation is that if we did not have access to what courses a student was taking, there is a lot of things we couldn't do today. The knowledge of what courses a student is taking is certainly not necessary to implement a directory service that is just looking up an e-mail address, okay?
So don't make the assumption you know all of the things you're going to use your directory for, day one. Day one, assume that you want to be able to do many things with your directory, so don't limit what data you can get your hands on eventually. That doesn't mean you put it all in to start with, but you --
HS: You set things up so that you can.
FG: You set things up so that it's easy to do --
HS: You set things up realizing that you're going to want to be able to do this.
HS: Okay, we have a question from Keith Brown from Duke University. And generally our rule has been that people send in two questions at a time, and Keith has sent in three. We'll handle his three questions anyway here, so perhaps we're setting a new standard for questions here, Keith.
Keith addresses Frank, but I think that either Frank or Michael could answer this. And his first question is, "If you were just starting to build your directory today, would you consider a meta-directory service like Zoomit or Meta Connect?" I've never heard of either of those, Frank and Mike. Have you?
FG: I have not either.
ML: I've certainly heard of Zoomit. I think they were purchased recently by Microsoft, so we'll probably see that folded into their technology base.
HS: What does Keith mean by a meta-directory service?
ML: A meta-directory is a directory of directories, for lack of a better term. Meta-directories allow you to -- well, let's use Frank's example, where you're trying to actually get as much data as you can at the institutional level and collect it. You make that data available in a centralized directory.
Now, if I have multiple application directory services on campus, and let's just say that it's a Microsoft environment, a Novell environment, I've got a Netscape Directory and, you know, Lotus Notes, to name a bunch of products. And I need to synchronize the data across those various vendor directories. I need a way to actually move the data from my central service into each of those vendor directories.
Meta-directory technology helps make that easy by allowing me to change the data in the meta-directory, the central repository. The meta-directory handles the synchronization of the data out to the various vendor directories.
HS: Okay.
ML: If I can, to take Keith's question up one more notch, I do think meta-directories have a place. Synchronizing data across the vendor products in a university environment where, at least in our case, we have at least two of each of these products is a necessary evil.
HS: So is it a necessary evil just for larger universities? Is that where you would see these things?
ML: I think probably most corporations have multiple directory services. The real issue, though (to take it up one level) is, as Frank said, to get your hands on the institutional data initially and identify that.
Now, using a meta-directory can simplify things. In our case, we've chosen to do our own synchronization across the products.
FG: In our situation, we are doing our own synchronization at this point in time, but I certainly have looked at meta-directory technology as an alternative to what we are doing. No matter which of the two ways you're doing it, you're accomplishing the same effect.
The big win here is that the application that you are developing -- just take one that is going to look for a person's home address, simple little thing. The HR data that you might have in your corporation is now being stored with product XYZ. You're in a migration to change your HR from product XYZ to product ABC. So all of a sudden, home addresses are being moved from one type of a structure to a completely different one.
If your applications are using LDAP and accessing a meta-directory service or a pseudo meta-directory service, they are picking up the definitive home address. They have no knowledge, nor do they need to care, that you've got a major HR project in the background that is completely changing where and how you're storing this data.
HS: Because this meta-directory stands between the institutional data and the actual LDAP directory?
FG: That's right. So now, when you're changing this back-end data, you're not changing all of the applications in your organization that depend on it.
HS: Okay. Keith's second question was, he says, "Again, if you were starting today, would you have a registry database to handle maintenance of the directory entries and then feed them to LDAP?"
FG: Well, to be honest with you, it was the last TechTalk that I did last spring that I finally learned that the database that I used to maintain my X.500 is actually called a "registry". So I first learned what that word was last spring. And I've been doing that for seven years!
So yes, the answer to the question is yes, I do use a registry, I always have. I just didn't know what it was called.
HS: Okay, actually you've just answered his third question as well, so that's fine.
JB: Okay, and let me just say, Keith, if you have some more information on Zoomit and the other product you --
HS: Meta Connect was the other product.
JB: Meta Connect -- if you want to send that to us, we'll see if we can do some links and get some more information. Or you can talk as an expert next time?
HS: Yes, give us the links, be an expert, you have lots of choices here!
JB: Howard, do you want to deal with some of the other questions here?
HS: Yes, we have a number of questions from Michael Grady, or a question from Michael Grady. He's from University of Illinois and he said, "I've heard Frank recommend in the past relatively flat names spaces for at least the person entries in the LDAP directory. Could Frank and Mike comment on the following? Should the person name space be as flat as all persons being at the same level?" Frank, Mike, you want to just comment on this whole flatness of the LDAP directory?
FG: Personally, we are going to a person name space that is flat underneath a people branch. Should I go through all three of the questions here?
HS: Yes, sure.
FG: Okay, the examples of problems that are caused by having a richer hierarchy is that you say -- say broken out by some combination of department, student, staff, etc.
First of all, by department. The number of people that we have that work for more than one department is quite large. It's quite common in a university setting for professors and researchers to be paid off of various budgets and actually have appointments that are joint across several departments. So which one of those places do I actually put this object if I'm going to break down by that?
The same is true of student and staff. I have plenty of people who are both student or staff or just one or the other and student is a real good example of another problem. If I have a breakdown by student, who is in that branch of the tree?
In our situation, we keep students in our directory for approximately two years after they last register. This is so that they can go to Web applications and actually come in and register again. During that period of time that they're there and can only do one thing, they really aren't students. So if they're in that branch of the tree, people can get the misinterpretation of that this individual really is a student at the University of Minnesota when, in fact, they have no such status at all.
I prefer these types of things as department, student, staff attributes, etc., to be attributes of an individual, not part of their structure in the directory. An example of things, if any that can be only easily accomplished if the people have a richer organization -- to be honest with you, a richer organization, the only advantage I can see is if you truly were going to browse the directory. That is, start at the top and start working your way down to the tree in a browsing-type fashion.
HS: And who does that? I mean, sounds like --
FG: Oh, I have no idea.
HS: Relatively rare to do.
FG: I actually -- we used to have a Gopher interface to our X.500 directory --
HS: Probably Gopher's not used too often.
FG: -- that did exactly that. So bring up a technology that was born and raised here at the University of Minnesota and was a precursor to the Web, did in fact do that. But we haven't done anything of that nature for a long, long time. And you can create those same sort of searches by doing attribute searches instead.
HS: Okay, we have another three questions here.
ML: Actually, can I take a shot at that?
HS: Oh, yes, sure. I'm sorry. Go right ahead.
ML: We are at the University of Michigan today running a very hierarchical directory, and as we realign --
HS: So your directory's not very flat?
ML: This is correct. It's actually caused some problems.
HS: So you disagree with Frank, then.
ML: As we are redesigning it, we are going to a flat name space, much like Frank has described, for the campus LDAP directory.
Now that said, in some of the vendor spaces again -- Novell and as we're looking toward Active Directory in the Microsoft space -- there are reasons to go with a hierarchical name space. Primarily is the ability to delegate administrative rights within your name space. So within a university environment, if you want to delegate administration of objects among schools or colleges, we're finding that a hierarchical name space actually works in some of those products.
JB: Would it make sense to have a hierarchical more at the department level rather than at the main campus level? Maybe that's --
ML: I don't understand the question, Judith.
JB: Okay, I'm sorry, I was probably jumping in here with my novice perspective on things. Is it possible that that might be achieved by having a more hierarchical function at the department level rather than a larger enterprise campus level?
FG: I think the issue that's being raised with the ease of administration with the hierarchical structure, I'm not that familiar with Novell directory services so I'm going to skip that. That may be a real good reason within Novell.
I'm looking in terms of I have an X.500 implementation on my back-end side and there, I can delegate the update authority to people based on the attributes that someone has. So this gives me the ability that if somebody, for example, is in both the math and the physics and the chemistry departments, all right? That's the professor's assignment. There could be a person with authority in math that can find and change that object, there can be a person in physics that can find and change that object, there can be a person in chemistry that can find and change that object. So actually that object is owned by three people vs. somebody else who only works for one department, that object's solely owned by the person responsible for that department. Am I making sense?
HS: Yeah. Can I get another question in here, before I go to this question that's either from Steve Thompson or from Peggy Butterworth. I'll tell you why we can't decide.
But another question about name space. In a lot of campuses, there's multiple campuses and therefore it's possible for people to have the same ID at different campuses. That is, somebody could have ID one at campus one and somebody else could have ID one at campus two. Is it important not to do that, to make sure that we have unique ID's in the name space? Frank.
FG: Yes, I believe it very much. It's very important.
Here at the University of Minnesota, our four campuses have done considerable cooperation in order to get duplicate ID's worked out so that we have a single name space from the point of view of the directory, and the people at the various campus levels can use the same ID and campus that we have assigned in the central directory.
This simplifies things greatly. It reduces end-user confusion dramatically and then gives you the added fact that you can start doing things like e-mail as simply user name and umn.edu and things of that nature.
HS: And I assume that you have one directory for all the campuses. You don't have separate campuses with separate directories.
FG: No, we do not. We have one directory that covers the University of Minnesota system.
HS: Do corporations do the same sort of thing? I mean, if a corporation has multiple branches, are they going to a single directory?
FG: I think within the higher ed, you'll see different universities making both choices, and you'll probably see corporations making both choices based on, you know, their internal needs.
Certainly I think within the University of Minnesota system, a single directory makes sense because students and staff can be very fluid and move between the various campuses from one semester to the next. And it makes a lot of sense for that person to retain the same ID, the same e-mail address, etc., as they go from one place to the other and there's continuity.
JB: Well, basically, though, that's an issue. That's kind of a question when you're getting started with directories is making -- that would appear to be a decision one would want to make early on.
FG: That's right. Here at the University of Minnesota, when we initially started directory services, it was not the case that we had a unified name space. This became something that we all realized it was an ideal place to be at, but day one, we simply couldn't just change everything and be there.
So it took cooperation and work on the part of all of us in order to get to where we are today. And I have to thank the coordinate campuses here within the University of Minnesota for the great assistance towards me in accomplishing that because --
HS: Yeah, it must have been some real agony when you run over to somebody and say, "Gee, we're sorry. You've had this ID for the last 15 years, but you're not going to be able to keep it."
FG: Because somebody else got it first, yes.
HS: Yes, because somebody else joined the university two weeks before you did.
ML: At the University of Michigan, we certainly dealt with that problem several years ago and I would recommend everyone go to one ID per user. For us it was a necessity out of deploying Kerberos services as an authentication service across campus.
HS: Well, since you mentioned Kerberos, that leads us just naturally into this question we have in our electronic mail that's on security. This question appears to come from Peggy Butterworth at University of Pennsylvania. However, there's a note inside this note from Peggy Butterworth that says "This really is being sent by Steve Thompson, who's using Peggy's cube." We can let Peggy and Steve figure this thing out here.
JB: Right, I was thinking about Dilbert, you know?
HS: Steve, don't you have your own cube? Don't you have a computer there? At any rate, Steve or maybe Peggy at University of Pennsylvania says, "Does LDAP support encryption as hosts communicate with each other?" That's the first question. Frank?
FG: LDAP itself does not support encryption, no, but it does enable various types of encryption.
One of the attributes that you can store in a directory would be someone's public key certificate for encrypting e-mail, for example, so that if I wanted to send you an e-mail, I could look you up in an LDAP directory, find your public key certificate for encryption, and then I could create an encrypted e-mail that I send to you so that as my e-mail goes from myself to you, it is encrypted over the wire in much the same way that we use SSL to encrypt a Web-based application.
HS: Are passwords stored in LDAP?
FG: Yes.
HS: Are they stored encrypted?
FG: Yes.
HS: Encrypted how? Or I mean, are they encrypted with VBS? Are they -- I mean, what scheme is used to encrypt them?
FG: What scheme do we use at the University of Minnesota or what schemes are possible?
HS: So there's --
FG: There are various schemes possible, all right?
JB: Why don't you talk about that for a while?
FG: VBS is a perfectly valid scheme. Unix password encryption is a perfectly valid scheme. We have one-way encryption scheme. End of sentence.
HS: Okay, so you have these one-way encrypted passwords stored in LDAP.
ML: The data's stored before it's stored in the directory. Or the data's encrypted before it's stored in the directory.
FG: That's right, um-hum.
HS: Right. But then you also have a heterogeneous environment. So I mean, folks are coming into Unix systems and Novell systems, NT systems and all this kind of stuff.
FG: That's right, but for example, if you wanted to do an authentication -- you wanted to use LDAP protocol to authenticate -- you would send a user name and password pair, hopefully over an SSL extension, to an LDAP directory. And what it would really be doing on the LDAP side is searching for a user name with that matching encrypted password and giving you back whether or not such an object existed or not.
HS: Okay, this wasn't part of Steve or Peggy's question. I still have two other questions pending, but since we're talking about this, how can LDAP help us get single sign-on, or should we bother to try to get single sign-on? I keep hearing people say single sign-on is a goal. It's certainly a goal here at Princeton. Does LDAP help you do that?
FG: Yes, it does. You certainly are on the road to having a single network ID for your entire university community. The directory can have a password -- or for that matter, passwords. We actually have more than one password for a particular ID, depending on its application.
HS: So with LDAP, in LDAP, you might have an NT password and a Unix password and a Novell password and a password for some administrative systems, and so forth and so on.
FG: Right. You might have a password that gets you access to one level of applications and another password that gets you access to a higher, more secure level of applications.
HS: But so your idea of single sign-on is one ID, lots of passwords?
FG: Lots is an incorrect word.
HS: A few.
FG: A few. Maybe two, maybe three. All right? One, well you certainly need one, but there are reasons why one is not enough.
I'll give you one good example. Every student, staff, faculty member at the University of Minnesota has an X.500 entry, and your X.500 user name and password gets you access to our remote modem pool. I really doubt that there are very many staff people who actually follow the policy that their Internet access is for them alone, and that they don't let their kids get on at least once in a while using their free University of Minnesota account.
It would be nice not to have the same password that they associate with modem pool access be the same password they associate with moving money around in the budget system.
HS: Okay.
ML: If I can jump in there.
HS: Sure, just proceed.
ML: Single sign-on, one of the keys for single sign-on or one of the paths many people are looking at is a Public Key Infrastructure. And if you're going to use a Public Key Infrastructure to enable single sign-on, campus directories (as Frank described earlier) for storing public keys for all users are indispensable. You've just got to have it.
FG: Right.
HS: And when you say Public Keys, you're meaning digital certificates.
ML: Correct.
FG: Right. That's the way the future is going to be, I think.
HS: Okay, Steve or Peggy's next question is, "Is LDAP compatible with a Kerborized or Kerberos environment?" Want to comment on that?
FG: I don't have a Kerberos environment so I'll pass on that one.
ML: We do have a Kerberos environment. The original implementation of LDAP v2 out of the University of Michigan included Kerberos services. I believe these were dropped in v3 where a SSL mechanism is supported and there are SSL plug-ins that do Kerberos as far as I know.
HS: For folks who don't know what SSL is, could you -- I understand that even if you say what it means, it might not mean anything, but let's try it anyway. What is SSL?
ML: SSL is an abstraction layer for authentication -- on server side.
HS: Okay.
JB: Thanks for asking, Howard.
HS: Yes, well, one never knows, Judith. Right? Sometimes you do the thing and it clears everything up and sometimes it sounds just like the acronym. Steve's last question is, "Does LDAP give some means to prevent spammers from harvesting your entire directory?" So how's LDAP secured?
FG: In our situation, a search of our directory will never return more than 50 entries.
JB: How many, 50?
FG: Fifty.
JB: Okay.
HS: So it would just take lots of time to get the whole thing. It doesn't sound like that's a real secure thing.
FG: That's right. I suppose if someone wants to start with AAAAA* and work their way down the line --
ML: It does make it difficult.
FG: Right.
JB: So in other words, that's still a challenge yet to be addressed.
FG: Right. We'd have to detect that type of a continuous search going on from a remote location.
JB: All right. We've got a couple more questions that are coming in as well. John Bucher (who in fact was one of our experts last week from EDUCAUSE) has a question about outsourcing, Frank and Mike. We actually started talking a little bit about this during our prep session. He's saying that they maintain -- he's from Oberlin College -- he says they maintain an LDAP directory but are very far from having all of the pieces together. So he's very concerned about how to do all this with a limited staff. And then of course, the follow-up question to that is how reasonable is it to look for an outsourced solution for this? I can see you want to jump right on this!
HS: Okay.
FG: So you'd like me to give reasons why I should have my job eliminated here at the University?
HS: No, it's not that simple. I don't think outsourcing eliminates any jobs.
FG: I know, I'm just giving you a hard time.
HS: Just for the record, though, I don't think outsourcing eliminates any jobs.
FG: For the record --
HS: It gives people a different job.
FG: That's right. And for the record, when you're looking at smaller institutions, I don't think that it's necessarily all that bad of an idea.
The University of Minnesota, I think, as well as every institution across the country, is having difficulty hiring and retaining qualified people in the field of Information Technology. And certainly all of the types of enterprise level services that an institution needs to run requires a high degree of technical expertise in order to run them. So when you're faced with that situation, it's not at all unreasonable to look at outsourcing pieces of your IT infrastructure, and it's certainly a reasonable thing to do as an alternative to continually hiring and training new staff.
But when you're looking at directory services per se, I think one thing that you do have to realize with respect to directory services is that when you wish to enable applications, this is something that the applications developers want to have happen rapidly. They usually come knocking on our door saying that they need that LDAP attribute about two or three days after their application was supposed to be already implemented. So they don't want to hear from us that they have to wait a month to get in. They want to see that turnaround relatively quickly, so you have to have good response there.
And also there is a potential with directory services. You are giving away the keys to the store because this is the future in terms of authorization and authentication at your campus with respect to PKI and all of the other technologies that are coming down the road. So this is a technology that you definitely want to have your hands on in terms of controlling its course. But you can control its course and still outsource portions of it, I'm sure.
HS: Okay, I see we're actually getting -- believe it or not -- toward the end of this session. Actually, we're even over a little bit, the 4:45 time here. But I thought we could certainly before we end it here, if we could just address the question that we started to talk about in the very beginning which is, there's lots of folks out there, lots of colleges and universities out there who haven't really gotten started on this. Maybe you could tell us what the first few steps are they ought to take to get things going. Michael?
ML: Start to identify the data. Identify the applications that you want to directory-enable.
HS: Don't you want to enable them all? So you're saying prioritize them.
ML: Prioritize them. What do you need to authorize people to do? And then my personal opinion, go after the privacy issues. What data do you want to make public, how much autonomy do you want to give your end-users in terms of their ability to modify the data? And go to work.
FG: I would modify that only slightly in saying that quickly identify the few pieces of data that you might want to have public and assume everything else is private until otherwise stated. So don't go through and try and have a massive data classification going on prior to being able to move forward. Just take the tip of the iceberg to get yourself started. Make sure that you're going to have good access to all of that data, though, in the future.
And then when you're picking your product to implement this, start out with the cheapest one you can find and get something started and get something rolling so that on the technical side, you get some experience behind you.
HS: What is the cheapest one you can find?
FG: When, Open LDAP -- that's a relatively cheap one. I don't think you can get any less expensive than that.
HS: Open LDAP is free?
ML: It's an open source solution.
JB: And people would know where to find that?
ML: I think that's the opposite end of outsourcing.
FG: Yeah, I think you're accurate there. It is the opposite end of outsourcing.
HS: Where do people find that? Can you give us a reference?
ML: I believe there's a www.openldap.org, but I would need to confirm that.
JB: Okay. Well, let's see. We'll try and get a source for that on the Website after the event here is over.
HS: Once somebody does this stuff, how important is it that they have some kind of security plan already on campus or that they integrate their security plan with this LDAP thing -- if somebody doesn't really have a security plan on campus, should they be doing this?
FG: I think the two can go in parallel. However, you have to be aware that your directory services is an application which you want to tie down and secure very tightly because it is the place that your authorization and authentication is taking place. And so, the data that is stored there has to be accurate and you don't want someone to have the ability to modify it.
JB: Okay, Howard, did you want to go back? I think there was one other correction that came in from Keith Brown. Did you want to highlight that for folks before we close out?
HS: Let's see, Keith did say -- there was something that said correction. He says, Keith just says, "Most popular LDAP services do support SSL communications to and from the directory server," and he points out, he says it's commonly called LDAP-S and was pioneered by Netscape. But --
FG: I think I misinterpreted the question as being does LDAP create support for SSL, not the -- yeah, you know, SSL can be run on any type of protocol, so there's no problem with running LDAP over SSL.
JB: Okay, good. At least we have a clarification and that's good. Thanks, Keith. Let's see, Howard, did we have any other technical questions of Frank and Michael before we close up for today?
HS: No, I think we've had a very interesting session here and I think we've given folks at least a couple ways to start out. I think we can't tell people how to do the entire thing because it looks like it's a very complicated thing and there's lots of things on the horizon that we might have talked about. We might have talked about XML, but it seems that's, there's not a great deal of information about that out there right now. So I think we've had a good -- not 45 minutes, a good almost-an-hour here.
JB: Okay, and also let me invite some of our listeners out there, if they have in fact just recently gone through a getting-started phase of their directories, then maybe they could send something to expert@cren.net and we could post that as part of the session.
So let me then thank all of our Web participants for being with us today for this time with our panel and to please send follow-up questions to expert@cren.net. We're trying to have follow-up questions answered sometime within the 24 hours following the session.
And be sure to mark your calendars for November 18th, which is two weeks from today. This TechTalk will feature Chuck Morrow Jones and Russell Morrison from Ohio State talking about their voice-over IP project, which is very exciting. You can also check the Website for other upcoming fall events, and as always, we welcome suggestions and feedback on both what you'd like to talk about here and who you'd like to hear on TechTalk.
Thanks to all the institutions who helped support these TechTalks by being members of CREN, and also thanks to everyone who helped make this event possible today: to the board of CREN; to our guest experts, Frank Grewe and Michael La Haye; to Howard, our technology anchor; to Terry Calhoun, event page producer; to David Smith and Patty Gaul of CREN; to Julia O'Brien, Jason Russell, Carol Wadsworth and the whole support team at the MERIT network; to Susan Berneis, our audio file transcriber; and to Laurel Erickson, our transcript editor and indexer. And finally, thanks to all of you for being here. You were here because it's time.
Bye, Frank. Bye, Michael. Bye, Howard.
FG: Bye.
ML: Bye.
HS: Goodbye.
JB: See you all online. Take care.
HS: All right, bye-bye.
JB: Bye-bye.
