Hi. My name is David O'Rourke. I'm here to talk about directory services/open directory. This is session 813. If you want a WebObject session, I suggest you go right across the way. I've introduced myself. I'm Server Engineering Manager. What we're going to talk about today is Apple's Open Directory.

That's a new name this year. We're going to review Open Directory as of Mac OS X-1. We're going to talk about our future plans for Jaguar. That's been a theme in the conference. I think you'll find that very interesting. Hopefully after learning about all this fantastic technology that we'll be talking about today, we'll be taking some questions and answers.

So what is Open Directory? I've gotten that question a lot this week. It's a new name. It covers client access and directory servers. So we see this as a complete solution for everybody. It combines industry standard protocols and open access technology. What we mean by that is that we're adopting industry standard protocols such as LDAPv2, LDAPv3.

NetInfo has been open source for a number of years. We're continuing to support that. And the open access technologies, we have both a client side API and a plug-in API that allows anybody to access any of the technologies. These are existing solutions that have historically shipped with Mac OS X already. So this really is a new technology. What we're doing is just bringing it out and showing people more about what it is, what it can do for you.

But we shipped this originally in Mac OS X 10.0. And it is now, as of this week, open source as part of Darwin. If you like that, I recommend some applause for some of the engineers in the corner that worked real hard on that. We're very excited about this. In fact, I bug report last night. It was kind of interesting.

So what is open directory? Again, I just went over that. Access. But what does access contain? Well, access consists of two main points. It's the Mac OS X directory service architecture and the existing lookup D architecture, which has been part of the BSD code or part of the Darwin code for quite a while. That is the foundation upon which client access has been built in Mac OS X to access authoritative directory data.

Directory server technology is for Jaguar. We'll be integrating open LDAP. But we also have NetInfo. We've been shipping that for a number of years. That is open source and that's our directory server technology. So LDAP and NetInfo combined. And we ship a number of integrated tools. We ship a number of integrated tools for managing the directory contents.

All of the tools in Jaguar, if you go to Jaguar system preferences and try to create a new user, that's using the open directory technology APIs to create that user record. If you go to logon windows, it's using the open directory APIs to verify the password. So we are integrating the management tools on top of this technology as well as just providing the technology. So this is a pervasive effort from Apple. As many of my coworkers in the audience will tell you, I visited them on numerous occasions telling, "No, no, no. You must do it this way." So we've been making some progress.

So what is directory services? This has historically been this session, but it's a little briefer this year. By and large, it's an open architecture that allows you to take your Mac OS X software, which is the blue box in this diagram, and base it on top of open directory services. On the back end, open directory services has existing plug-ins for NetInfo, LDAP.

This year we're adding BSD flat files, so apparently SciTech wants to use Etsy files for the configuration. And other plug-ins. I believe we have some third parties that have shipped plug-ins on the lower layer, and we're working with some universities on developing plug-ins. So directory services is a read-write API abstraction that if you put your software on top of it, you don't have to care about what directory Mac OS 10's been used to get its users and groups from.

Okay. So what does Mac OS 10.1 include as part of directory services? Well, it includes a v2, an LDAP v2 plug-in. It includes a NetInfo client. And it includes full documentation for using the directory API and writing a plug-in. Some of that documentation is in the form of developer documentation and other documentation is actually published on the Mac OS X server website.

We have a white paper, for example, that tells a customer how to integrate Mac OS X into an existing active directory server. The goal there was more as a demonstration of our LDAP connectivity, not so much as a demonstration of active directory. But we have documented access API and a plug-in API. We have an SDK.

Calling an SDK is really kind of an overstatement. What it is really is a collection of sample code that shows people how to use the directory service APIs. You don't need to install the SDK to use directory services. I've received that question a lot. But everything you need is in the Core OS. But if you want to see some sample code, you can do that. You can download the SDK, you can download the code, see some stub plug-ins, get some other information about directory services. The SDK has, I guess, augmented or additional information.

And that can be downloaded from the URL that you see there on the screen. The headers, if you have a PowerBook, you're welcome to inspect the headers right now. Open it up. Go to /system/library/frameworks/directory/s ervices. You'll find the headers there. Although, it'd probably be better for you to pay attention to the presentation.

What is Mac OS X One Directory Server? For Mac OS X One, we include NetInfo, which we feel is a powerful, scalable and very, very useful directory service to ship with the operating system. It's part of Darwin. It provides both standalone access and shared network access and this is a fantastic server. Moving forward in Jaguar, we're going to be augmenting this directory server architecture with an open LDAP server.

Mac OS 10.1 directory tools. The directory tools that we use for directory services are largely provided by server software or desktop software, and they're included with the operating system or with the directory server or with the desktop OS. These are the Mac OS X server administration tools, which are entirely based on the open directory technologies.

NetInfo Manager uses NetInfo, and that allows you to set up the open directory server. NetInfo Domain Setup is a tool we ship with Mac OS X Server for setting up directory servers or setting up NetInfo. And there's a number of command line tools, ni-dump, ni-grep, a whole list of ni tools that are management tools based on the open directory technologies.

I've received this question and this was a slide my management wanted me to have in here for years. I just got around to doing it this year. How does Mac OS X use directory services? And if you look at this diagram, it's a very, very subtle diagram. But whenever somebody calls a POSIX call like get PWName or get hostname or something along those lines, it dispatches on the left side of the screen and dispatches down to an existing process in Mac OS X called LookupD. LookupD handles the request and dispatches it and reads directory data.

What we've done for Mac OS X and JAGUIRE is we've tied LookupD in with directory services. So regardless of which API you're using to access directory data, if you're an existing POSIX application accessing directory data or a new application that's using the open directory APIs, you get the same data out of the system. So what happens is LookupD is a pluggable architecture. We've written a plugin for LookupD that we call DS Agent.

DS Agent dispatches all the data requests to the directory services side. It's a very simple way to do that. But whatever plugins have been enabled in directory services, LookupD benefits from that data. If you're calling directory services directly, it just dispatches to directory services, dispatches to the plugin, and accesses the directory data. So this is pervasive and fundamental in Mac OS X.

Any time you look up a user record, any time you look up a group record, any time you look up a mount record for an NFS mount, the data's coming from directory services. What directory services allows a customer to do is tell the operating system where their preferred place for retrieving that data is. So if you're calling a server, you're calling a server, and you're calling a server, you're calling a server.

That's the way it's going to be. You can do that with any of the different services. You can do that with any of the different services. You can do that with any Open Directory and Jaguar. That's the past. We've already done all that. We've already shipped all that. What we're here to talk about today is what we plan to do tomorrow. And that's Jaguar.

What are we doing for Jaguar? Open Directory will support LDAPv3, ReadWrite, Native, SSL, everything that was requested for the past year. We will support BSD/Essie files and we're adding some more plugins which will be talked about later in this presentation. For servers, we're including OpenLDAP. It is the OpenLDAP that is already downloadable and runnable on Mac OS X. It's server and client. The server is OpenLDAP. The client is the LDAPv3 plugin we're including with directory services.

And the LDAP server will share the database with the NetInfo server, so there's no need to migrate your data. If you already have a NetInfo database set up with users, groups and mounts in it, you fire up the open LDAP server and it will use the same database. If you add a record through LDAP and create a user record, it gets put in the database.

If you delete a record, it shows up as deleted on the NetInfo side. So this will allow our customers and our developers to migrate very gradually from NetInfo to LDAP or keep NetInfo or keep LDAP. So you have the best of both worlds and you don't have to set up two separate databases on the system.

New authentication options. There's going to be an extensive talk on this later in the thing. Readable crypt passwords are going away. If your application... Thank you. If your application needs to do password validation, you can no longer assume to get PWNAM returned to your readable CRP password. There are abstractions that you will need to adopt so that you can verify user passwords in the system. There's a lot of effort going on here. There's a lot of work. I'm not going to try to steal Jason's thunder later in the presentation.

We have a great presentation for you in that area. Enhancements we're going to cover today. My intro section is almost done. I'm going to be bringing up some of the engineers who actually do the work as opposed to stand up on stage and do presentations. They're going to be talking about open source.

They're going to be talking about directory proxy, which is a very interesting new feature. We're going to be talking about LDAPv3. We're going to be talking about the BSD config file plugins. Then we're going to cover authentication and service discovery. How many of you just came from the zero comp talk? We're going to be talking about service discovery at that top layer that Stuart said at the end of his presentation and how we support both Rendezvous and Apple Talk and how this becomes an integrated story so that we support all the service discovery protocols until Rendezvous takes the world over in about three weeks. and this time I'd like to invite Ken Witzk up on stage and he'll be talking to you more about directory services. Thank you.

Okay, first off, I've been working on directory services for over two years now. And I am really excited to be here. I want to be able to share the knowledge I've gained through those two years with everyone here. So let's talk about our first three topics we've got here.

What we got here is open source, where we are, we're going to talk about where we are today and where we're going with Jaguar. For Directory Proxy, we're going to talk about what this means for remote access to open directory. For LDAP, we're going to talk specifically of the enhancements we have added since 10.1.

So I know it's been mentioned many times already. Open Directory or Directory Services is part of open source now. You can go get it at that URL. What does that mean? That means that directory services for 10.1. The product that is shipped right now is the product out there. The source that was used is now open source. What it also means is that any development that we have done in Jaguar Up until this point is also open source. We haven't left anything out.

Now included in that is the API, the daemon, the plugins as we have written them, LDAPv2, NetInfo, search. This is a fantastic opportunity for plugin developers to see how we have done the code and to tell us how to improve upon our code or to take and run with that code and make their own plugins for their own access to their own directory servers.

For Jaguar, we plan on also open sourcing DS Agent. which is a plugin for LookupD. Currently, what we call DS agent in LookupD is a static A static library included inside LookupD itself. It is open source now. We also plan on releasing LDAPv3 plugin, full read/write. and as Dave has mentioned already, the BSD configuration file plugin. and we have a series of service discovery plugins that we also will open source and my colleague Jason will talk about that later in this presentation.

So let's move on to directory proxy. What does that mean for remote access? What we want to be able to do is allow administrators to remotely access across the network the open directory on a server, i.e. maybe a server in a closet somewhere. Maybe that administrator had gone home for the day and he wants to connect in via VPN to access that server to update something. In either case, We want that remote access.

To that end, we have made it, I believe, very concise on how to do this conversion or add this capability. We need to understand the API dispatch models as they exist today. And we'll go through that right now. The local dispatch model, we have an open directory client. That uses the Directory Service Framework using Moch. An API request is sent to the daemon. The daemon then properly dispatches it to the plugin that will process the request.

www.kent.edu/dirtyservice-diamond-blogsp ot For the proxy model, here we have, let's say, a client machine A. Another server machine B. And the first thing we need, of course, is our network. The nice thing about this addition here for proxy is that The players still stay the same. The only addition now is the network. We have an open directory client, a directory service framework, We sent a TCP/IP request across the network. It gets to the daemon. There again the daemon dispatches it to the plugin. The plugin processes. It goes back.

The framework receives it. The request is done. So the question is, how did we accomplish that? Well, let's talk about the key thing in here is we have 128-bit encryption. It is a secure connection.

In other words, if you are accessing remotely, you need to be an administrator on that remote machine to gain access. For existing applications out there, client apps that exist today, the changeover is very simple. It consists of one API change.

Currently we have a call to DSOpenDir service and then a series of calls like DSOpenDirNode, DSGetRecordList, whatever the other API calls are. The change is in the initial call, now we just need to call DSOpenDirProxy and then the framework takes care of everything underneath. The proxy call would require an IP address, a username and password. That's it.

Now I think a lot of people are interested in LDAP. This is from a client perspective, not from a plugin perspective because this is our plugin we've developed. The first thing we're adding is LDAPv3, read-write. You know that already. You've heard it a couple times. SSL comes with that.

The second thing we've done is we've added Minimize Configuration Setup. And this is pretty cool. We'll touch on that shortly. The third thing is we've expanded our record definitions to handle more complex schemas. In other words, we've listened to our customers and we've responded here. And lastly, we've also added OpenLDAP Server itself on Mac OS X. So let's move on to minimize configuration setup.

What we have here is a client zero configuration story. An iBook coming into a network, receiving information via DHCP and retrieving information via directory services. to enable an LDAP directory server node to be placed on the automatic search policy. The two components of this are DHCP option 95, This is where the DHCP server supplies to its clients the LDAP URL that directory service uses to extract server information.

The other component is that we have come up with a way to store our config information that is now currently set up through directory setup or now what we will be calling directory access remotely on the server itself. So there's no going around to every machine to set up your configuration.

We realize that a lot of LDAP schemas are complex. So what we've done is enhance our ability to accommodate that. First off, we're adding full object class support. That is, instead of just using search base, you will be able to use object class, discriminators, for defining record types, standard record DS record types. Secondly, we've added specific attribute mappings on a per record type basis.

by automatically generating default values for what we call the LDAP schema must attributes.

Open LDAP server in Jaguar is based on version 2.1.x. All changes that are made here on Mac OS X will be released back into the source tree. It's LDAPv3 compliant. and lastly as Dave has already mentioned, we want this, we have a shared data store and we want interoperability between LDAP and NetInfo clients to that data store. Now to get a feel for the LDAP enhancements that we've made, I want to invite Jason Townsen up here to give you a short demo.

Alright, so here I have a Jaguar machine and let's just take a look at what we've done with directory access to configure LDAPv3. So you'll also notice before I get into that that we've got a bunch of plugins here. So if you remember on 10.1, if you've ever looked at directory setup, there was LDAPv2 and NetInfo.

And now we've got BSD configuration files. We've got LDAPv3. We have some new plugins for service discovery. Directory access is also where you configure your authentication and contact search policies. So authentication is what is used when you log in at login window or over personal file sharing. And context will be used when you're searching for email addresses in address book or mail app.

So LDAPv3, you select LDAPv3, click on configure, and you'll notice we have a sheet now. It starts off with just showing the option of whether or not you want to use our DHCP LDAP support. But if you wanted to do some manual configuration, you can disclose the window, the sheet, and get a list of locally defined servers. This is kind of similar to what we had before. So let's say I want to do a custom configuration first.

I'll just bring up the edit dialogue for that. Go into search and mappings. This is similar to what we had in LDAPv2 for record and attribute type mappings. For this example, I'm just going to map groups and users. So I can select both of those and add them. And you'll notice when I map users, I have search base, as we've had in the past.

So I'll say dc=apple, dc=com. But I can also add object classes like I could say inet org person or POSIX account. I could also require that both of those object classes be present for any record of the user type. In addition to that, I could add specific attribute type mappings only for user records, such as the real name and record name, just to give you an idea.

For real name, I might want to map that to CN. And record name, I could map to CN and UID. Actually, you know what? I want to put UID first. So I'll just drag that around and then we've got that. So that's the attribute mappings. Now we can also have global attribute mappings that would show up in this top group called default attribute types. So for that I could add a global record name mapping. And then I could add a global record name mapping.

and just map that to CN. So groups would get CN as the mapping for record name, whereas users would get both UID and CN. OK. So that was a lot of work, wasn't it? And you can imagine if I actually mapped all of the attributes that we really want, like unique ID and password or primary group ID, that it would take quite a while to do that.

So something that we've added as part of the support for DHCP LDAP is the ability to say I want actually a server config. So here I can, I can manually The domain name of the server and then for the mappings pop-up, pick from server. Then optionally specify a search base where those mappings are stored.

and I'm done. Now, if I had a DHCP server that was set up to tell me the URL to this LDAP server, I wouldn't have to do anything. But you can also have an intermediate step where if you want to manually assign IP addresses, you can still use server-based configuration for that. All right. So let's go back to the slides. So, let's go back to the slides.

So, let's We're going to talk about authentication and service discovery on Jaguar. As Dave mentioned, we are moving beyond crypt passwords on Jaguar. Applause if you feel like it. Thank you. So you may know, if you're applauding about this, you probably know what Crypt is. You know that Unix is historically based on Crypt, and Mac OS X has used Crypt stored in the user's record in NetInfo.

On Jaguar, for any particular user, this may not be the case. We may be using an MD5 password stored in the user's record instead of crypt. We might be using the password server or Kerberos-based authentication. Let me interject and say, for Kerberos-based authentication, if you're interested in this, stay where you are, because we've got the Kerberos session coming up next in this room, and it's going to be great. I encourage you to check that out.

In order to support all of these different types of password storage, you need to use one of our password verification APIs. Don't use getpwnam and crypt, because when you call getpwnam, there's no guarantee that a crypt password is going to come back for you. So you need to use one of these abstractions. So let me go over them.

There's three of them that we've listed here. The security framework provides password verification and a standard user experience. This is what's used when you're clicking on the lock button in directory access or in system preferences. So it's used often when you need to gain administrator privileges to do something. The second one is PAM, or pluggable authentication modules. This is an API that is available cross-platform on Linux and Solaris and other BSD platforms. So, it's a good choice if you want to do cross-platform code and keep the same APIs across all your platforms.

Finally, we have Directory Services. Directory Services is the most flexible because it allows you, in addition to simple password verification where you have a username and a password and you want an answer of yes, that's good, or no, it's bad, you can do a challenge response authentication, such as APOP or CRAM MD5, and support that authentication through a server, such as a mail server.

Directory Services provides no standard user experience. It's a low-level API, so that would be a reason to go with security framework if you need the user interface. So now that we're adding all these types of password storage, how do we know when one of these requests comes in what to do? Well, we've added a new attribute called the authentication authority. This is an optional attribute for the user record, and it tells us what we need to do to authenticate that user.

We've defined four major types of values for this attribute. We've got basic. This is the legacy behavior, which is crypt. The second one is basic specific, which would be used, for example, for MD5. Any other type of situation where you're storing a hash in the user's record, but you might need a different transfer function. The third one is password server. I'm going to go into more detail on that soon. And Kerberos. We're looking to expand this in the future, so we may add more in the future, but we've designed it so that it can be extensible.

So, some of the example values you might see, the format is semicolon delimited. We have the version, the tag, and optionally tag data. In the case the attribute is missing, which would be, which would happen when you, for example, you upgrade a 10.1 machine to Jaguar, we continue using Crypt as we have in the past.

If it explicitly says basic, we will use Crypt. And then we've got some other examples there. For basic specifically, we might say MD5. That would tell us what the function is to use for, to create the hash. And for password server, we would store in the data the network address of the server and an ID for the user. And for Kerberos, we could specify the Realm name.

So, I've mentioned password server a couple of times. This is a really exciting feature that we're adding in Jaguar Server. And it's based on a standard called SASSL, which stands for Simple Authentication and Security Layer. This is a standard that was developed to add Secure authentication support to existing protocols such as IMAP or FTP.

But we've taken that standard and made it into its own protocol with the password server. So every time an authentication is performed, there is a SASSL method in use and it's a standard that could potentially be proxied through directory services through a particular server like a mail server.

The password server provides only password verification. This is very important because it means that there is no password recovery over the network. So it's not possible to do an offline attack against a password server across the network. The other big win that we get by forcing everyone to use the password server any time they touch a password is that we can enforce password policies.

So we can say that this user, for example, must have a ten character password or greater, or all of the users on my password server must have ten character passwords. Also, we could say that every three months I want the password to expire and the user have to reset it.

So let's take a look at an example of how we might use the password server. Here we've got Mac OS X client, a Jaguar server, a directory server and a password server. In this example, we're representing all of these as separate machines, but depending upon the layout of the network, we could just have all three of those servers running on the same machine or combine two of them. It's totally flexible in that respect. So the first step is that the authentication information is sent from the client to the server. This would include the user name, for example.

Second step, the Jaguar server will look up the user's record and Directory services will consult the authentication authority to determine what type of authentication to perform. And in this case, the user's record will say this is a password server user in their authentication authority. So the next step is that the password is verified using SASSL, using the appropriate SASSL mechanism For that scenario. So depending upon whether the ClearText password is already provided to directory services or it's using a proxy, one of the authentication methods will determine which one gets used. Finally, we have success. The client is given access to the server.

As I mentioned before, we're using SASSL. We're supporting existing methods that were defined by IANA for SASSL over TCP/IP. We've also added some new ones. Some of the existing ones, examples might be CRAMMD5 or APOP. Some of the new ones include two-way random and The password server also provides a secure set password operation. So even though the password change is happening over the network potentially, it's not sending the password in the clear.

So, to review, we're going to support more than just Crypt. So, to get ready for that change, your application needs to be using one of our password verification APIs. And if you use those APIs, then the password server will be transparent to you. and you won't have to do anything else. Also, if we add additional authentication authorities in the future beyond Jaguar, you'll pick those up when they come online too.

So let's talk about service discovery and shift gears a little bit. I'm sure basically the entire room here was over at the rendezvous session. I was there. And so this is a really exciting area for Apple right now. From the perspective of directory services, we've got an API called Network Service Location.

That's our high level API for service discovery. This has been available as part of TENS since day one and it actually was available on nine as well. It provides access to the raw data if you need that or you can put up a standard user interface. An example of this that you're probably all familiar with is connect to server in the finder uses NSL.

In Jaguar, NSL is entirely based on open directory. So this means that we're merging both static directories like LDAP along with dynamic directories like Rendezvous and presenting them all together through the same abstraction. It also means that when you write a directory services plug-in that your plug-in can be available to NSL and show up in Connect-to-Server.

As we mentioned before, and you saw in Directory access, we've got a bunch of new service discovery plug-ins. Apple Talk, SLP and Rendezvous are just some examples. The other change is that we've provided a new logical structure in the connect to server dialogue. There's a local item which provides a collection of all of the service discovery data that is considered local to your machine.

Rendezvous on the local multicast would be part of that, as well as your default SLP scope, your local Apple Talks zone, the local NetInfo domain, and so on. Then if what you're looking for is not local to you, you can go to the network item and that has the full hierarchy of everything that's available.

So existing applications that are already using NSL will automatically benefit from our new plug-ins and will not have to change anything to continue working. So NSL will automatically, in the connect to server dialogue if you use that, convert from the rendezvous data into a URL that you can use.

So service registration is the other half of this. If you're writing a server or a service and you want to have support for discovering it on the network, you need to register. You should add support for Rendezvous and register using either CFNet services or the low level DNS service discovery APIs and continue supporting legacy service discovery for maximum compatibility.

If you're being browsed by a Mac OS 9 machine, then you might want to continue using Apple Talk or SLP because that will not have support for Rendezvous. You should also consider, when you're looking at service registration, adding a preference so that a network administrator could decide that they only want to use Rendezvous on their network. and give the administrator the choice rather than assuming that you should register on everything always.

So in summary, NSL is a high level convenient API to use for service discovery. It provides support for many protocols including rendezvous as well as existing protocols. It's got support for the raw data as well as the high level human interface. and you should add Rendezvous Service Registration to your product because this is Apple's strategy moving forward and we believe it's going to be much better than anything we've done in the past. Keep in mind, though, you should allow the customer choice as to which of these service discovery protocols they should use.

At this point we've got another demo. So, go back to the demo screen. And I just wanted to show you what I mean by the local and network items in connect to server dialog. So, here I've got local. I take a look at that. There'll be a couple of items showing up here.

Right now I'm only using, on the client side I've disabled a couple of plug-ins you may have noticed before in directory access. Actually I have Apple Talk on still, but I've disabled SLP. Right now I'm only looking at The next slide is a little bit more complicated. I'm going to show you a little bit more of a list of the things that we're going to be talking about.

I'm going to show you a little bit more of a list of the things that we're going to be talking about. Here's one that's coming over Apple Talk. This is actually the machine right next to the demo machine. What I can do is, if I want on the client, I could disable AppleTalk in directory access, and that would take it out of connect to server on this machine. But it's only changing what my view of the network is. I'll just go ahead and do that. Maybe turn off. MDNS is the name of the rendezvous plugin in the Jaguar seed.

So if I do that, go back, take a look at network. OK. So now nothing's there. But if I turn AppleTalk back on, Maybe I'll get something. Actually, it looks like I'm getting nothing. Anyway, but the point is that now that we have all these plug-ins and directory access, we have control over which service discovery protocols we're using as a client.

And in addition to that, it'd be really great if the services started giving people this control so that we could use the service discovery protocol that's best for the environment that we're working in. At this point, I'd like to hand it back to David O'Rourke for a summary.

and the rest of the team. There's the machine. We're going to cover just a quick summary to go over what we did and hopefully highlight some of the points and then we'll bring Tom Weyer up, who I'm sure you're all familiar with, to go into some Q&A. This has been a big week for us. Open Directory. Directory Server, Directory Access, Directory Tools.

Open source, download the source, email us with your bugs, email us with your source enhancements, email us with your feature requests. But also use this as a repository if you have custom site requirements. This provides a fantastic source base for you guys to start with. If you want to modify the LDAP server or your LDAP client to do something just slightly different than how Apple shipped it, it's now completely possible for you to start with our LDAP plugin, modify it and deploy it at your site for your needs. Jaguar features. We've got an LDAPv3 server and client story. We've got read/write access.

We've got a near zero comp story on DHCP integration. I want to spend a little bit of time on this and just reemphasize this. The goal of this is that someone can take an iBook into an institution or managed network, open it up and from the DHCP server configured on that campus learn about the LDAP server without them having to go to Directory Access at all. I think we've substantially upgraded Directory Access, made it easier to use. We'll be looking for your feedback based on your experience with it. But the goal really is that they shouldn't have to go to Directory Access at all.

Not even just click one or two buttons. They should have to do absolutely nothing. We will learn about the LDAP server automatically and automatically configure all of our schema mappings without anybody having to do anything. So we've got read/write, DHCP integration, the ability to download our configuration from the LDAP server itself so I don't have to visit 3,000 iBooks and reenter that information. And we have complex schema support so that we can accommodate more of the schemas that have already been deployed at many sites.

We have Directory Proxy, which is a very interesting feature that allows you to take your existing directory API based application and allow it to remotely go out and see the directories from the perspective of another machine on the network. This makes remote administration tasks almost trivial if you've based your read/write software on the Directory Access API. We have authentication changes.

If you take one message away from it, that perhaps should be the message. We are going to try to get rid of Crypt. Your app should get off of relying on the Crypt. Get on to an abstraction API. Security Framework, PAM, Directory Services. Work with Tom, work with me, work with anybody and we'll help you determine what the right abstraction is for you to adopt in your application.

Jaguar features NSL which is a long standing technology and the engineer who brought it to us is in the audience. He's been working on it hard. He and I have been cooperating the last year to get NSL off of its own plugin architecture and onto directory services so that it could automatically benefit from the LDAP v3 work we were doing, the search policy work we were doing, the automatic and zero-conf work that we've been doing to discover DHCP and the rendezvous work. We've been working very closely with Stuart Cheshire and all of that work.

We've reorganized NSL so it now has a notion of what's local to you and what your network is. We think there's a lot of enhancements there. Add rendezvous registration to your networking product. I saw the demo in the keynote of iTunes. You saw Stuart's demo today. Rendezvous is a very exciting technology. This is something everybody who does networking software should be looking into.

Jaguar servers. We're going to include a SASSL based password server. We think this is a huge deal. It will allow you to get your passwords out of a readable database and into a centralized and hopefully safe repository to where people can't download the password database. It will also allow you to support authentication methods. It will allow you to enforce policies.

Jaguar Kerberos support. You heard that in the server session. I believe it was mentioned in the keynote. There's this whole session, a whole hour and a half after this session for which we'll be talking about Kerberos. Apple's putting a lot of effort into Kerberos and we're very excited about that.

For more information, again, Stuart Cheshire had a really interesting point in his zero comp. He kept saying Apple, we didn't invent anything here. We're not trying to invent anything here. Well, to some degree, the directory services team has taken the same vein. Apple seems to have arrived at this conclusion at similar time points in life. LDAPv3, we didn't invent that, but we're adopting it and making it better. SASL, we didn't invent that, but we're adopting it and we're going to make it better. Directory service and location, NSL, all of this is existing documentation. That's the second bullet on the slide.

And directory services is, once again, open source. For a roadmap, so you need to go back in time and go to Tuesday at 2 p.m. and you would see me speak about directory services being open source. Then you can hang out for another day, eat at a different place Tuesday night, and go to the session on security Wednesday.

Zero comp networking only requires you to travel back in time a couple of hours. And stay in your seats. Don't let anyone take them. In fact, the room's already full. I don't think we should let anybody new into the room. For the Kerberos talk. Let's not, they were late.

They didn't come to my talk. They shouldn't deserve to see Kerberos. So, if everyone will just stay in the room when we're done and tell everyone else to go away who cares about Kerberos, that's coming up right after this. and The person to contact is Tom Weier. In fact, I recommend you register that email address at any website you visit or anything along those lines.

Hopefully some of the email that he'll receive after me telling you to do that on tape will actually be relevant to this session or other sessions that Tom's been responsible for. So I appreciate your time. At this point in time, I think it's time to play Stump the Experts and there's microphones in the audience and I'm going to invite Tom Weyer up on stage.