TechTalks Transcript
Building a Directory: What Are the E-ssentials?
December 13, 2001
Audio
• Streaming
MP3
• Download
MP3 (Download
Tips)
 Judith Boettcher [JB] |
 Howard Strauss [HS] |
 Frank Grewe [FG] |
 Steve Kunz [SK] |
JB: Welcome to the CREN Tech Talk series for fall of 2001 and to this session on Building a Directory: What Are the E-ssentials?� 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 our session is coming to you with the support of the CREN member institutions and our Microsoft, the maker of the Active Directory. Let me welcome Howard Strauss of Princeton as our technology anchor. As you know, Howard is a well-known web technology expert and portal expert. Hi, Howard, how are you today?
HS: Hi, Judith. And thank you. I noticed you said e-ssentials instead of E-ssentials. I suppose e-ssentials is like e-mail and��
JB: E-commerce and, yeah, right.
HS: All of those things.
JB: You�re very fast at picking that up.
HS: Okay. I�m Howard Strauss, the technology anchor for the Tech Talk series of technology webcasts. And today, we�ll engage our guest experts, Frank Grewe and Steve Kunz, in a lively technical dialogue that will answer your questions about directory e-ssentials and we�ll ask Frank and Steve those very important follow-up questions. We�d be glad to have you ask your own questions by sending e-mail to expert@cren.net anytime during this live webcast. If we don�t get to your questions during the webcast, we�ll provide an answer in the webcast archive. If you don�t know where you�re going, any road will take you there. Getting where you�re going requires some vision and some directions to tell you how to get there. For a university to get where it�s going, it needs the necessary data to make critical decisions in real time. Our campuses have collected great oceans of data which are usually treated as the sovereign property of some department. This data may have errors, may be out of date and may be in formats incompatible with the rest of the university or even the rest of the civilized world! But departments tend to guard it with militaristic zeal anyway. As with the World Wide Web, with over a billion web pages, a vast quantity of data does not make decisionmaking easy. It makes it harder. An office administrator on campus is considered highly skilled for just being able to root through seas of data and finding the tiny amount of information critical to run an office. Forget about decisionmaking! It take so long just to find a real budget balance or to update a person�s data who has just gotten married that there�s no time left to make decisions based on the data. And by the time all of the necessary systems are updated to reflect a newly-married person�s change of status, the person could be divorced! Directories are a way of bringing together useful subsets of the information that by and large universities already have. Most of what is in a directory is probably already somewhere else on campus. A directory just gathers data from diverse sources and puts it in a more convenient and more accessible form. Once in a directory, data can be accessed very quickly. Since directories tend to be built for special purposes, applications that use them get just the data they need. While all data is vulnerable to security threats and oversights and programming and process controls, damage to directories can be quickly and reliably repaired since they are copies of the original data, not the original data themselves. Since applications that access the directory tend not to access the original data, the original data gets an extra layer of protection. Your Information Technology group�s responsibility is to get control of university data and use it to make everything the university does better. Building directories is a critical part and natural extension of that mission. If you don�t know where you�re going, you�ll probably end up somewhere else. When it comes to directories, our two experts, Frank and Steve, have a very good sense of direction. They�ll keep us on the right track as we explore the essentials of directories on today�s webcast of Tech Talk. Judith?
JB: Well, thank you, Howard. I think in your introduction, you really did raise a number of issues and I know that one issue we struggle with with directories online is the fact that we want applications to know us, but we don�t want them to know us too well or be able to share information too easily. So we�ll have a chance to explore some of these issues as well. Let me first introduce our first expert for today, Frank Grewe from the University of Minnesota. Frank is a manager in the Academic and Distributed Computing Services unit of the OIT office with the University of Minnesota. Frank is back for a return visit as a guest expert to give us an update on what�s new and exciting about the University of Minnesota directory program, now almost ten years old. Frank, welcome.
FG: Thank you! Happy to be here.
JB: Great! And then our second expert is Steven Kunz from Iowa State University, just a bit south of the Twin Cities. Steven is a Systems Analyst/Software Engineer at Iowa State and one of the many projects he�s been working on recently is the Windows 2000 Enterprise Services implementation and some of the Active Directory implementations. Steve has been at Iowa State since 1997 and therefore knows, I imagine, almost everything there is to know about the systems at Iowa State. Welcome, Steve.
SK: Thank you! It�s nice to be here also.
JB: Great.
SK: One correction. I�ve been here since 1977.
JB: Oh, dear, I thought I said that!
SK: I think you said �97.
JB: And it is all on your website!
HS: Now, Steve, is that in a directory somewhere? When you started?
JB: It�s actually on his personal homepage that�s linked.
HS: Okay, but a personal homepage is not a directory! Frank, maybe you can tell us, when we say directory it probably means a lot of things. But could you give us the scope of what we�re talking about when we say directory?
FG: Well, the first thing that I guess I would like to distinguish is between a directory and a database. Most of the time, we think in terms of databases of information where we are doing constant updating, where we are very concerned about backing out transactions and this sort of thing. A directory is not, in my view, a database. It�s something quite different. Its function is to provide quick, reliable searching and lookup of information and the updating of a directory that takes place in the background is a secondary operation. As you said in your introduction, directories can completely fail and be rebuilt from scratch, so they don�t have the same types of restraints on them that a database does and I guess this is my first distinction between a directory and a database.
HS: A lot of folks, though, as sort of a data processing principle will say that you should only have one copy of something. You shouldn�t have information in 27 different places because of the synchronization problems here so why is a directory a good idea when it�s just a copy of data you have somewhere else?
FG: Well, one very important rule is that, yes, you do want only one copy of the data that is your source data. You don�t want to have a feed from your HR systems, for example, into your directory that would allow that data to be changed independently in your directory itself. You want one authoritative source for all information. However, a database for HR or student records or alumni, etc., has a lot of requirements on it in terms of batch processes that must be run overnight, backup of the database. It must go offline for a wide variety of reasons and all of these would be interruptions in service if applications needed to access this information 24 by seven. So a directory out in front of your database allows applications access to the information that you have at your institution in a 24 by 7 reliable way and it�s not affected by all these needs that a database really has.
SK: Can I��
HS: Go ahead, Steve, you�re up.
SK: Honestly, I�m sorry. Yeah, and it�s also good to remember that many of the directories have�are historical in nature. There may be special purpose directories that have information spawned off of your central databases that fit into a nice, tight, compact, efficient thing like a Finger server or a PH server or some other type of legacy server.
HS: If you�re going to use these UNIX terms
SK: Oh, I�m sorry! Well, anyway
HS: You�re going to have to explain them to the people who have lived their whole life on the NT side or somewhere else.
SK: Well, there are special purpose servers that have been around several years and it�s often easier just to spin off data onto those and let them live their lives, using the authoritative source, as Frank mentioned.
HS: Can you give us, Steve, some examples of directories? I mean, it sounds like you�re both saying that the university doesn�t have a directory, it has lots of them. Can you give us an example of some of them?
SK: Well, I mentioned a few already. A PH server is an old phonebook server that was one of the original online��
HS: That�s a white pages kind of server?
SK: Right, right.
HS: That�s something where you just look up people�s names, addresses, phone numbers, kind of thing on campus.
SK: Right, right. Just an online phone book. A Finger server is UNIX, as you detected, a UNIX style server where you can��
HS: I have some early UNIX detection software.
SK: Where you can Finger a username and get information, much like PH server, get their e-mail address, sometimes whether they�re online or not, some personal information about them. You can also have Active Directory that we�re using here as another type of special purpose directory.
HS: That�s an NT thing.
SK: Now Windows 2000 and Windows XP, actually.
HS: Okay.
SK: NT could have another directory in that you could have a directory on an exchange server in an NT domain and that could be a directory where you�d get people�s e-mail addresses and so forth. You could have a Netscape directory that served off information and you can have an NDS directory from Novell where your Novell users and trees and organizations and objects and so forth are stored into and you�re going to be very hard pressed to find a giant Swiss Army Knife style of central database server that meets all of those specific directory needs.
HS: Frank, why do we need so many directories? It sounds�I mean, Steve has just given us this huge list of directories.
JB: Sounds like a dozen or more, at least.
HS: Yeah! I mean, wouldn�t it be nice to have one?
FG: Well, it definitely would be nice to have one. However, the impossible goal of having all applications software talk the same way to each other is still a ways out there in the future.
HS: But is that where people are going? I mean, is that the big arrow in the sky saying��
FG: Well, I think the key element is a standard spaced directory. Some of the types of directories that we just mentioned are�some of them are standard spaced, some of them are proprietary. In the case of the University of Minnesota here, we have one directory that allows for access by most of the Internet standards, Finger, Who Is, Gopher, HTTP, LDAP, etc. And then we spin off from that those directories that are proprietary such as Active Directory. We don�t spin off NDIS but we could, if we wanted to do that one as well. But oftentimes, the easiest way to solve a problem is simply to create yourself a new directory with a specific purpose for it rather than try to backstitch a brand-new and somewhat troublesome application into your existing directory. Given that you have properly collected the data from all the various sources, these tend to be relatively straightforward things to do.
HS: Are these directories, Frank, flat files? When you�re contrasting them between databases which tend not to be flat files, is that a characteristic of a directory?
FG: In our particular case at the university, our directory for people objects is completely flat. We have one hierarchy that has all of the students, staff and faculty of the entire statewide system of the University of Minnesota in one flat portion of the directory. We have no hierarchy on it at all.
HS: And it looks like a single table so it looks like just a single relational file?
FG: Yes. However, it is searchable by a wide variety of attributes on the object. In other words, it�s searchable more than just by the key of the object. You can search by many different attributes that a person has.
JB: And you said that that was a statewide system, Frank?
FG: Right, for us, the directory service, I provided the top, our top level directory server is for all campuses of the University of Minnesota, all research stations, etc.
SK: We have a very similar thing at Iowa State. We have an I Planet server which services out basically our people database that has all the faculty, staff and students in one large flat LDAP accessible database.
JB: How many entries are in your directory, Steve?
SK: Well, I don�t manage that directly but I think it�s probably around 36,000.
JB: Okay, and just to get another data point, Frank, for the Minnesota��
FG: We�re getting close to a quarter of a million.
HS: Quarter of a million entries?
FG: Yes. And to back off on that just a bit, probably the first thing you�re wondering is how can I possibly have that many active people at the University of Minnesota?
HS: Yeah! Right. [inaudible]�
FG: The answer to that is that a person lives in our directory, given that they have at least one entitlement for an application here at the University of Minnesota. A person goes into our directory when they are accepted for admission and they leave our directory five years after they take their last course, so that�s a pretty extensive time on the student side for a person to��
JB: I almost thought you were going to say that they leave when they�re dead, Frank. I�m glad you didn�t!
FG: Well, I don�t know [inaudible].
HS: You raise the question about alums. Do alums hang around?
FG: If dead folks can somehow pay tuition, they stay here! On the staff side, we have new requirements on the staff side that a person stays in our directory for the full calendar year after they leave, so if somebody leaves sometime in 2001, they will not go out of the directory until December 31, 2002. And the application that�s driving that is the one that allows people access to their W-2 information.
JB: Ah, interesting! Okay.
FG: They need to have access to that through at least October of the year after they have last been paid.
HS: Do you keep alums in this directory?
FG: Alums�well, a person is kept automatically for five years after they [inaudible] course.
HS: But not after that.
FG: And alumni, after that point, they can join the alumni association and maintain an account in that manner if they choose.
HS: Is that a different directory?
FG: No, it�s not a different directory, but it is a different data source.
HS: Okay, Steve, one of the things that we hear directories are used for is authentication and authorization. Could you talk a little bit about how that�s done/�
SK: Well, at Iowa State, we have�I was mentioning before, the people directory where we have this flat persons file where you can look up individuals that is linked to a central database where we keep all of the security information. And basically, we�I�m drawing a blank, I�m sorry.
HS: That�s okay. Frank, can you tell us how authentication and authorization is done?
FG: Sure. Here, authentication takes place because somebody knows their username and password and that identifies who they are. What they can do is dependent on the application and becomes a combination of criteria. First of all, there is the attributes that the person has in the directory itself. Those attributes govern some high level aspects of what they can do. Things such as are you registered for classes this quarter is known by the directory and since we get feeds from the student system nightly, if someone registers today, the directory will know that they�re an active student tomorrow. Likewise, if they withdraw from classes today, the directory will know that they�ve withdrawn from classes tomorrow. The same is true on the staff side in terms of their employment status. So many of these types of things are best kept in the directory as general high level things that all applications can depend on. Then, there are applications which by their very nature want to limit access to them by a list of people I know I want to let into this. For example, I want to let the person responsible for finances in each department into a financial application or something like that. The data from HR has never been data that can easily identify roles. Roles are quite different from job titles and that�s one of the issues, I think, everybody fights with is while you know people�s titles from HR, you don�t necessarily know the role they�re playing this week.
HS: Because they�re too broad. You�re saying that the titles are just too broad.
FG: Well, you might have a person whose title is really your financial person for the department, okay? But that person goes on vacation for two weeks each year, and who takes over that role while they�re gone? All right? And so�or maybe that person shares that role with one or more people who have a completely different, lower-level title than that. So there does get to be some confusion, you know, in that. Also, you could have temporary deans whose HR indicator would say they�re nothing more than a professor, but they are acting as dean of the department for a period of time, something like that.
HS: In these directories that you�re talking about for authentication, do you keep passwords there?
FG: In our particular case, we do have the password in the directory, although that�s not necessary. A lot of places have a Kerberos type environment which they authenticate against or other types of things that they authenticate against. In our situation, we�ve never had any applications requiring Kerberos so we haven�t gone there. And we do have the password stored as an encrypted attribute in the X 500 directory itself, much like a UNIX password would be.
SK: We do have Kerberos at Iowa State. That�s where I got lost, trying to link the two together! The indexes for both our flat people file and the user ID in our Kerberos database, the principle name, are the same entry and so even though the password is not kept in the I Planet, even though I Planet would tell you that it could be, we split it off and use MIT�s Kerberos and do our authentication out of the Kerberos database. Now, when we talk about Active Directory, Microsoft has its own implementation of Kerberos and we chose the same scheme. What we do is replicate the same user ID that is in our flat people file and in our MIT Kerberos database down into Active Directory and so the username and password is synced between our UNIX systems and our Microsoft Active Directory systems.
HS: It sounds like we have a lot of sensitive data in these directories. Is there any special things we do to make sure these things are secure?
FG: Security for directory data is definitely a priority here at University of Minnesota. The servers that I have that are actually the directory engines themselves do not have IP addresses that are routed out on the Internet and there�s no reason for them to do so because all of the protocol interfaces such as LDAP, Finger, HTTP, etc. are on completely separate machines from the directory engine itself. This is part of our scheme here in order to protect the data that�s on those directory engines from being examined. I mean, there�s a wealth of data there, if nothing else, a great mailing list for university
HS: Yeah, but does anybody encrypt the entire directory? I know you encrypt the passwords, but does anybody encrypt the whole thing?
SK: Not to my knowledge, not in the ones that I deal with.
FG: Not to my knowledge.
JB: So the point of security, then, is by maintaining that distinction between the directory engines themselves and the access to those engines. What about access to the servers and the databases that feed the directory? Are there security policies and concerns there or is that left up to individual departments and groups?
SK: Speaking for Iowa State, when we get out feed of data from our administrative data processing department which collects the raw data and feeds it to us in a stream�sounds much like Frank�s system�basically, it goes into a very large secure central database that we use to fan out to our member directories, the ones that are target directories. Nobody really gets in and can query that from the general public and the data is all very secure because it has Social Security information and other things that may be considered private. And it includes flags that say, from the people who don�t want their directory information published. Then as the feeds go out to the other directories, basically policy rules related to how that person wants to be exposed or what we can expose for that person publicly are handled right at that point. So nothing gets loaded into a publicly accessible data that isn�t ever allowed to be seen, or if it is put into a directory, for example in Active Directory, then we make sure that there are access control lists on those attributes so that only qualified or people who are supposed to see that information or update it can see it.
JB: It does sound like, when you�re getting data from multiple data sources, that there would be a real challenge in terms of synchronization of that data. Is there some basic principles or issues that you could�that you might like to�that you find work for you?
SK: Well, we really have a model of the authoritative sources come from, like, Human Resources and student records and admissions and so forth. Those are the authoritative sources. And when we get them, we fan them out and the changes, for example, in Active Directory down below don�t replicate back up because Active Directory is not considered authoritative for the source of information. It�s basically a one-way feed.
JB: Oh, interesting, okay.
HS: We have a couple questions from Randall Morey at University of California at Davis and actually, his first question has to do with authoritative sources, but I think it�s a little different than the question you asked, Judith. He says, �If you populate the directory from source data systems, how do you find authoritative sources when more than one system can write an attribute?� Frank?
FG: When more than one system can write an attribute.
HS: Yeah, I think what Randall is saying��
FG: In other words, if I would get home address from the Alumni Association and home address from the student system, which one would I believe?
HS: Yeah.
FG: I think that�s probably the question. I�m going to guess that�s what the question is.
HS: I think that�s what Randall�s asking.
FG: Okay, and I�ll tell you what my answer is. My answer is I have two data items. I have home address from student systems and I have home address from the Alumni Association! I don�t pretend for a minute that those two data items are the same thing. I treat them as if they�re different.
JB: So you include them both in the directory.
FG: Right. I would either be selecting one or the other as the one I�m going to show the public or I would show both.
HS: How do you decide which? You�re saying you don�t choose one or the other or you do choose?
FG: I would either be choosing one or the other as being the one that white pages, for example, would display, or I would be showing both as being different types of addresses.
JB: What policy do you have?
FG: And the policy on that is that I would be sitting down with alumni and student records and they would tell me what to do, not the other way around.
HS: How�s that at Iowa, Steve?
SK: Well, we basically get our data feed from, as we mentioned before, administrative data processing and we don�t go out and retrieve information from other sources. So what we�re looking for is official university records.
HS: So you tell those folks to fight it out.
SK: Basically, yeah, whatever ADP sends us we consider authoritative.
HS: [inaudible] one thing.
SK: Right.
HS: That�s a good way, just move the problem back or up or out.
FG: Well, it is an advantage in that, on the one side, as you worded it, move the problem back. But that�s really where the problem belongs and it�s not so much that the problem belongs there as it is that you have to respect who the definitive data sources are, who the data owners are and allow them to be the ones that determine how their data is displayed and what it means. Because they�re the ones that really understand it best. An HR system will have multiple addresses for an individual, for mailing address, the address you have for tax purposes, all sorts of things like this, and you�ve got to know which one is the right one to show for home address, which one is the right one to show for business address, etc., etc.
HS: Okay, Randy Morey has another question. I think we�ve answered, actually, the first two. And he says, �If a directory is used for authorization, describe the impacts that can result from duplicate entries in the directory.��
JB: Maybe we want to check and see whether do duplicate entries ever occur in the directory?
FG: Duplicate entries can occur, first of all, in the source data, all right? And usually those duplicate entries are a temporary thing. An example I might pull out is someone who has been taking night classes and then gets admitted to day school and for some reason or other when they were admitted to day school, it wasn�t picked up that they were a previous student and they get assigned a new student number. And that situation might last for a bit until the person who�s involved realizes that their transcript is wrong and when they check things out, oops! There�s two people and they ought to be just one. Yes, for using the directory for authentication purposes in this type of a situation, potentially I suppose has problems, but if you really look at the situation, each one of the person�s multiple entries�let�s say I was in the directory twice. Each one of my entries is going to have only part of my true picture instead of all of it. So what�s really going to happen to me is that if I use one of those identities, I won�t be able to do some things and if I use the other identity, I won�t be able to do some other things, all right? It�s not going to result in my being able to do too much, right? So from a security standpoint, I�m okay. The problem that it�s going to bring up is that I as the end user am going to find that I don�t have access to something I should have access to, not the other way around.
JB: Interesting, okay.
HS: Over here, as in many places, people wind up with many ID�s, net ID�s. I mean, I have three of them and I probably have fewer than many people here.
JB: I always suspected you had multiple personalities, Howard.
HS: Yeah! But with this directory stuff, are we trying to move in a direction that says people should have one network ID and one password? Is that where we�re trying to go?
FG: My answer is yes. At the University of Minnesota, historically we did create two entries for people who are both student and staff and that was because historically, our old legacy system, the feed we got from HR and the feed we got from student systems, it was nearly impossible to be able to reliably identify someone who is the same person on both feeds. Now that our university has completed a transition to PeopleSoft, we do know that an individual is the same on both student and staff side and now we�re in the process of going to one ID for a person instead of two.
HS: How do you then synchronize all the passwords? I mean, PeopleSoft does its own authentication and other systems do their own authentication [inaudible]��
FG: No, in our situation here, the web access to PeopleSoft uses your directory username and password for access. So for example, if I want�a student who wants to go into PeopleSoft to register for classes, what they do is enter their directory username and password and when they do that, when they enter the application for registering for classes, what the application turns around and does is ask the directory, �What�s the student ID for the person who�s out there on the network?� And the directory hands back, �Here�s the student�s ID.� So then PeopleSoft knows what record in its database to be updating for course registration and things like that.
HS: But people log on to UNIX systems, to NT systems, to administrative applications. Don�t they all have different passwords? How do you pull all those together?
SK: Not at Iowa State.
FG: Not necessarily. I�ll quick answer for us. When you get down to the departmental level, departmental LANs, those LANs in general do not use the X 500 password. They may have synchronized the usernames but it�s very unlikely they would have synchronized passwords. I�ll pass to Steve.
SK: Okay, what we�ve had for many years is a self-registration system for users that links back to that central people database that I was talking about, and so people can go up to our labs, click a register button and get a user identity when they enter the university and if they answer the proper challenge questions that match what we have in our database�and that could include information like student ID and so forth�then they can assign themselves a single user ID that they will use originally for all of our UNIX systems. Now, where we�re moving right now with Active Directory, as I mentioned before, this synchronization process from the master database and the Kerberos MIT authentication down into Active Directory, now we have the same username and password down in Microsoft�s implementation of Kerberos v. 5. And as we move the various departments into the Windows 2000 Enterprise operation, then all of the various departments�and this is if they choose to participate in this scheme�as they shut down their NT 4 domains and join the Enterprise domain, now the user has a single signon good for, in a student�s example, the four or five years while they�re here at college that gets them access to any of our UNIX lab machines, any of our Windows lab machines and we�re working on the Macintosh end of the single signon also.
JB: Let me step in right now for just a moment and be sure and invite others that are out there listening too that this is a really good time to send in some questions regarding the directories for Steve and for Frank. I think as far as a follow-up question on the domains, Steve, you mentioned an Enterprise domain as well as other domains. Is there conflicts or competition between domain names on campus or is that something that�can more than one domain live on a campus?
SK: Are you talking about Windows 2000 domains? Or NT 4 domains? Obviously, we�ve had many departmental NT 4 domains for many years on campus and they�ve pretty much picked their own domain names and functioned with their own set of accounts and they manage their own users. With the advent of Windows 2000, we brought in Microsoft consulting services who recommend that we create a single Enterprise forest with a single domain in it and then move the departments into OU�s and let them manage their resources out of the OU�s. Then what that results in is a single user identity that is common and can have resource shared access granted to resources amongst any of the OU owners who happen to own the resources. And so the single identity then lets you share resources across a campus�speaking about Windows 2000 now. It lets you do scheduling, if you�re into Exchange 2000, now everybody is in a common directory all across campus so that people can have time scheduled by other people across campus and the issue of having one identity becomes very important when you�re trying to schedule that person for a meeting. If you go to a directory and find five entries for the same Joe Smith, you really don�t know which one he�s going to be using that day for scheduling.
HS: Can we talk about standards just for a bit here? One of the standards for directories is LDAP. Can you tell us, is that the most widely used standard and just what is it? Steve?
SK: Windows 2000 uses LDAP for Active Directory and the I Planet server that we have our big flat people lookup database on uses LDAP and so basically that�s the direction we�re moving at Iowa State.
JB: Are there other standards that are important as people are developing their directories? I mean, like does XML have a role in directories at all?
FG: Oh, boy!
JB: That�s a hard one, huh?
SK: Yeah!
JB: Frank, are you using that?
FG: I would say positioning yourself for the new network protocol is�whether it�s LDAP or PH or Finger or XML or whatever protocol you might want to have, that�s really nothing more than the way the data is being moved between one application and another or between a client and a server. And it�s important that there be standards in that, but naturally as we go forward in years to come, there�ll be new standards that will provide us with things we haven�t thought of yet. As far as things are sitting right now, LDAP is probably the standard that provides us with the best solution to our current needs and so if you�re going into directory work for the very first time, I think it�s pretty obvious that LDAP is a protocol that you absolutely must support.
JB: As people are getting into directories for the first time and there�s probably a lot of campuses out there that, while you�ve been at it for ten years, Frank, that they haven�t really gotten started very much yet. Is there just a real easy point for people to get started with directory?
FG: Well, my personal opinion on it would be that every campus probably has a printed directory today and the data that appears in that printed directory has some authoritative source somewhere. To go as your first step to develop a simple LDAP white pages seems to me to be an obvious entry point for everybody. And you�re going to need at least that much before you can get into any more complicated things such as authorization and authentication.
JB: Okay, but that�s one place for people to get started.
FG: Certainly, and by the time you get that up you will have accomplished a lot because some of the roughest work that you�re going to do in building your directory is understanding the data you�re getting from data sources, getting a good relationship between your group and the group that provides the data, understanding what their requirements are in terms of what can be displayed publicly, what cannot, what are the data rules in terms of your use of this data, all of that is necessary just to put up the simple white pages and that�s really a lot of the hardest work that you�re going to go through in your directory, right there.
HS: What�s the first application you�re going to put up that uses LDAP?
FG: White pages would use LDAP.
HS: That can?
FG: Oh, sure. The Microsoft Find People LDAP client or the Netscape Address Book LDAP client, either of those can be pointed at your LDAP directory for searching your white pages for people.
HS: Okay, what about the EduPerson standard. Could you say a few words about that? What is that, who�s using that, how does it fit in?
FG: Well, one of the problems that we�re hoping to solve with directories is the ability for institutions to cooperate and to be able�that someone who is at Iowa State might be able to access resources at the University of Minnesota and vice versa. In order to do that, I need to know something about the Iowa State person or they need to know something about the University of Minnesota person that they can use as a judgment as to whether or not this person should have access to their resources. The EduPerson directory attributes has been an attempt by the Internet 2 community to come up with a set of initial attributes that can have some very standard-specific meanings across all institutions and so we can populate those attributes with values and when I query Iowa State�s directory about this attribute, it has the same meaning as when they query my directory about that attribute. And we can write applications, therefore, that can share that and understand and communicate back and forth with each other.
HS: Are you using it? Is Minnesota using EduPerson?
FG: We have the EduPerson attributes defined at this point, but I do not have any application with another institution that is making use of that. There are several things coming down the road in the Internet 2 community that will make use of it. Shibboleth, which is authentication between�various institutions will be making use of it. There�s a CREN Mellon project for PKI that also has a potential of making use of these attributes. So I put them in and defined them because I want to be a good member of the Internet 2 community as fast as possible and the applications that�ll make use of them are just over the horizon. I would suggest anybody who�s listening to this to go to the Internet2.edu site and take a look at the middleware presentations that are in there and they can see many of the things that have been worked on using directories and authentication and authorization and PKI as well.
JB: Right, actually most of those links are right on the event site so people can go ahead and start there and they�ll find a wealth of related links.
FG: I might as well make a plug for everyone to go and become�get PKI started by getting a root key assigned by the certificate authority, how about that?
JB: Okay? Well, you know, I think with that we�ve got a number of questions coming in. Howard, you were going to ask one, I think.
HS: Yeah, we have a question from Lisa Campeau from University of Pennsylvania and Lisa says, �Does anyone use directories to handle non-persistent users such as library patrons or gym users?� Steve?
SK: Hum!
HS: Do you folks do that?
SK: Well, we�re addressing the issue and I guess the short answer is yes. We have many of the departmental NT 4 domains would have visiting professors that�d be presenting seminars and so forth and they would hand out temporary user ID�s for a weekend or a month or whatever. And our formal structure, you could only get an account here at the university if you were officially affiliated. In other words, you came in through out ADP data feed. And so that was one of the first concerns addressed when we went to Active Directory was the departments said, �But now when my visiting professor comes in, they can�t get an account here.� And so we had to create an exception process for them so that, within their own organizational unit, they could create a temporary account and then blow it away after that person went, separate from the entire university�s formal, official person status.
FG: We do something similar here. We have a web interface that allows privileged people to create guest accounts and the policy is that any department at the U can designate a person that they would like to have this authority and then that person is able to create temporary accounts in our directory for visiting professors, for consultants, etc. It is required that temporary patrons to our athletic services and various types of library patrons have a temporary account in the directory prior to them being able to access those resources. The only exception that I can think of where we don�t have the individual in the directory itself, there are a few web applications where any random person on the Internet can come in and ask for an identity so that the next time they come back, they have saved information about themselves in their previous session so they have�I don�t know what to call it other than maybe the same thing as going to sort of a Yahoo ID or something like that, where you can have something that�s persistent and you come back to the same identity time after time. But you�re not required to be a member of the university community at all in order to access those web pages so that�s why that type of identity would not be in the directory.
HS: Um-hum. We have another question from John McCoy at Mills College in Oakland, California, and under the subject �Tools for Syncing User Passwords to Directories,� John says, �Are the schools having to build their own tools for doing the migration or are tools being provided by the directory manufacturer, and if so, which ones provide these tools? We are a small school and cannot reinvent the wheel each time.� Frank? Steve, that�s
SK: No, no, no, let Frank go!
HS: Either way, doesn�t matter to me. Anyone can answer here.
JB: You both probably have a good suggestion here.
SK: Yeah!
HS: Frank.
FG: Well, is this for password synchronization?
JB: It�s for syncing user and passwords, I think. I think it is a synchronization, Frank.
FG: In my situation, the password is stored at the top level directory and at the time a person makes the change to it, it is changed there and also pushed to the one other place that we have it at the present time and that is Active Directory. And both of those updates in our situation is homegrown code, so I�ve got homegrown code in both.
HS: Are there any tools that you know of?
FG: Well, I think that Steve wants to jump in here because he�s got the perfect solution to that!
HS: Okay, so take a��
FG: So I�ll shut up.
JB: Go for it, Steve!
SK: It�s a solution that I�ve heard of. Microsoft makes a tool called MSDSS which is Microsoft Directory Synchronization Service. It�s�what I understand, it�s a very large and complex tool to set up and get running, but basically what it does is you teach it where your directories are on campus and which ones are authoritative and which fields should be moved to other, non-authoritative areas. And then after you provide all the authorization and everything that it needs for all the authoritative places, it sits in the background and runs, updating fields and will handle a wide range of directories that are sitting out there.
JB: And what about your Iowa State implementation, Steve?
SK: The Iowa State implementation, like Frank, is totally homegrown. We invented a secure encrypted interface between our Kerberos servers down to Active Directory and use Microsoft�s ADSI Active Directory programming language to accomplish the task.
JB: Okay, and hopefully John will let us know whether that was what he intended with his question.
HS: We have one more question here from someone who prefers to keep their name not mentioned, okay? But I think it brings up an interesting point. The person wants to know when will the Exchange Directory project be completed at ISU? What is the Exchange Directory project? I�m just curious to know what the Exchange Directory project is.
SK: Oh, my God!
HS: What is that project? I guess I don�t care when it�s going to be completed, I just wonder what you�re doing.
SK: Well, of course, like any campus, we have a lot of departmental Exchange 5.5 servers sitting all around and with Active Directory and Windows 2000, what Microsoft did was they took the directory out of the Exchange 5.5 boxes and moved it to Active Directory. So you only have one directory, and so the Exchange 5.5 people, as they want to move to Windows 2000 and Exchange 2000 to keep up with the current technology, they need to have the central infrastructure, the central Active Directory in place and a method defined for them to migrate from their stand-alone NT 4 Exchange 5.5 domains into the Exchange 2000 domain. And we�re in the middle of another Microsoft consulting services consultant engagement for several weeks now, getting expert advice on how to do that. The short answer for the ISU user is they should attend the Windows Administrative meeting tomorrow morning at 9:00. We�ll be giving a status report.
HS: And you�re going to notice who shows up at that meeting!
JB: You�ll probably
FG: He�ll be the one with the real guilty look.
JB: Yeah, you�ll figure that out, no doubt. We are getting terribly close to the end of our session today. Is there a final issue or principle, Steve and Frank, that you�d like to share with people as they�re putting up their directories, maybe the most interesting issue that you�ve had to address? Frank? Steve?
FG: Oh, boy!
SK: I�ll go ahead and start this time, Frank.
JB: Okay.
FG: Okay.
SK: It�s sort of interesting. Our directory project, and I�m mainly keying on Active Directory again, has been dealing with the collapsing of NT 4 domains and bringing them into the main structure, a single directory structure. And you tend to focus�or at least I do�to focus on the technical problems and then the political ones come around and hit you behind the head and you�re not really expecting some of them. And what you have to remember when you�re thinking in terms of a single directory and single signon and ownership of data from authoritative sources that may not be in the departments, you�re actually removing functionality or control from some of the departments. So for example, the department IT manager who used to be able to change the name of a person or change the phone number directly in their directory structure. Now, the authoritative source is in university records and even the account that they used to be able to delete, rename, suspend at will now belongs somewhere else in a single central directory. And when you move toward an Enterprise structure, then you have to go through some of this�you have to sell your services, in short, and say, �Look, it�s really a win-win situation when you get to here.� But the perception is oftentimes a loss of control.
JB: Initially, they feel like they�re losing control, right?
SK: Right.
JB: Frank, did you come up with something in the meantime?
FG: Not really. I found Steve�s comments interesting. I think they�re very true. At University of Minnesota we�ve taken our approach to Active Directory just slightly different from Iowa in that we have instead of organizational units within our one top level domain, we actually have lower level domains. That was driven by other requirements that we have. We actually had Microsoft consultants, too, so they don�t necessarily come up with the same answer for every situation. And we populate people not at the highest level domain, but down at the lower level domain, and that allows the departmental LAN administrator a little more flexibility than if it was up at the top. One of the things we found to be very, very useful, however, with our top level directory is to empower departmental level people to be able to manage the objects that are within their department. So for example, we will allow a department to designate someone who is able to change passwords, do this sort of work for people who are in the same department as they are and this takes a lot of work off the helpline because people who have problems are not calling our helpline. Furthermore, they�re still helped by somebody who�s right there on the floor with them, the same person who helps them with their LAN is able to help them with their central stuff.
JB: So it�s that person at the elbow that can be right there for them.
FG: Right.
SK: We do a similar thing at Iowa State by moving the faculty and staff users into the organizational units so that the local IT managers can manage them. We do with OU�s what Frank does with domains.
JB: Okay, so it sounds like you both did really come up with the same solution, but just from a different path. Okay.
HS: They�ll agree to that!
JB: Howard, what do you think? Do you have a final question?
HS: Yeah, I just wonder, we�ve done four sessions on directories now and Frank, you said you�ve been doing this for ten years. What do you see happening in the next two or three years that�s going to change any of this? Is there anything significant coming?
FG: Boy, I don�t have a good eyeball for going over the horizon more than three to six months, to be perfectly honest.
HS: Okay, well, even what�s out there on the horizon.
FG: But what I think is the important criteria, though, in terms of being prepared for it, okay, and let�s just make the argument we have no idea what�s coming in six months
HS: Okay.
FG: �but we want to be prepared for it. That is the idea that you have got your data feeds from all your authoritative sources down, that you�ve built yourself a repository where you�ve identified individual people, eliminated duplicates, done whatever else you need to do and are able to�if you can feed one directory from all of this, feeding another one, feeding something new that we haven�t even heard of yet is going to be simply a technical problem and you will not be rehashing all of the data issues that you really need to go through very carefully in your first round of putting up a directory. I guess that�s where I�m [inaudible].
JB: So in other words, it�s the foundation.
FG: The foundation, that�s what�s the important part. That�s why I would strongly recommend shooting for white pages, you know, something simple as your first implementation because no matter how simple it is, it�s really going to bring out all of the data issues that you will have in your institution.
JB: Okay. Howard, are we ready?
HS: I think we�re out of time here!
JB: Out of time! All right, well, listen, thanks, everyone, for being with us here today and be sure to continue to block off your Thursdays, alternate Thursdays in the spring and particularly January tenth when the spring season will begin again. We�re taking a short holiday break and hope that you enjoy your holiday as well. And we�re always planning for Tech Talks so do send your suggestions for topics and experts in to CREN at the CREN number, or expert@cren.net works as well. Many thanks to the CREN member institutions and to Microsoft who brings you Active Directory Services for their sponsorship of today�s session. Many thanks to our Tech Talk experts for today, Frank Grewe and Steven Kunz, to technology anchor, Howard Strauss; to Terry Calhoun, Tech Talk web guru; to Jason Russell, Bonnie Boyles, Gayle Terkeurst and the support team at Merit Network; to Susie Berneis, audio file transcriber and if you haven�t tried the MP3 files, do so with your new MP3 players you�re all going to be getting for Christmas. And finally, a thanks to all of you for being here. You were here because it�s time. Bye, Frank, Steve, Howard. See you all on January tenth.
HS: You betcha! Bye-bye.
FG: Bye.
SK: Bye.
END OF WEBCAST
