We're going to talk about what's old in directory services today and what's new in directory services because I've been told that some percentage of you have never been to a WWDC, so you don't know about the brilliance and mastery that is directory services. So we'll go over some history and we'll bring you up to speed on what our plans are for Leopard.

So the agenda is really simple. What is Open Directory or directory services as we interchangeably refer to it as? How is it used by the system? We'll be talking about what you can do with Tiger today because spring 2007 is, I guess, the announced date from yesterday's keynote.

So that means that we've got at least six months of the existing Tiger product for you to use and there's a lot of features in directory services that I've been surprised people don't know about. So we'll bring you up to speed on that. And then we'll be talking about why you're all really here and why you paid your money, but we'll be talking about what we're doing with directory services for Leopard. And then hopefully if there's some time left at the end, we will have a short Q&A or a long Q&A. depending on how quickly I talk through my slides.

So what is Open Directory? Open Directory, I get this question a lot. Open Directory is a technology name, kind of like Quick Times and Umbrella technology. It's no one thing. It's a lot of different things. Open Directory is the way we refer to both our client and our server technologies. And what we try to do with Open Directory is integrate and promote industry standard directory technologies or authentication technologies like our adoption of Kerberoos.

Open Directory is built into Mac OS X, the Mac OS X server. And it's open source as part of Darwin. So there's no magic in Open Directory. You can go download the LDAP plug-in, the BSD local plug-in, the directory services daemon. It's all posted on the Darwin website. It always has been. We actually have some customers that have modified the LDAP v3 plug-in for some minor tweaks. It's always helpful to me to talk a little bit about history. So in Jaguar, the things in white were not new to Jaguar. The things in yellow were new.

So in Jaguar, we introduced the LDAP v3 plug-in. We introduced the NIS and the flat file plug-in. We introduced AppleTalk, SLP, Bonjour, and SMB. And we had NetInfo, LookUpD, and LDAP v2 from Puma. But that's so long ago now that I didn't want to fill the slide up with Puma or Cheetah. For Panther, we continued adding things to Open Directory, the major addition being the first release that we supported the Active Directory plug-in.

We followed on with Tiger with trusted LDAP v3 binding, which allows you to trust that the directory is open. So you can see that the directory server you're actually talking to is the one you configured to talk to. And we added MemberD, which is a key new system daemon in Tiger that does nested group resolution and was in support of the file system ACLs, which were introduced in Tiger.

And then what we're here to talk about today is Leopard. And I'm not going to give away the entire presentation on the third slide, so I left that blank for this thing to keep you guys in the room. So we have the requisite layer diagram. So the Active Directory services is this middle layer.

Below Directory services are a series of plug-ins. You can write these plug-ins yourself. So far, not a lot of people have. They are difficult to write because they're part of the trusted system. But we have plug-ins for accessing a local database. We have a plug-in for accessing LDAP.

We have a plug-in for accessing the /etc files. And we have Active Directory and NIST, all as plug-ins underneath Directory services. And the rest of the operating system sits on top of Directory services to some degree. Login window would be in the red box. Workgroup manager would be in the red box.

Server manager, for those of you familiar with Server Admin, would be in the red box. Anything that looks up a user or a group. In some cases, in a twist, the kernel actually sits on top of Directory services because when it needs to do a group resolution to check a file access privilege, and if it doesn't have the group in memory already, it has to call Directory services to fetch it. So a lot of the operating system sits on top of Directory services.

So directory service is the green layers in API for read/write access to the configuration. And this was one of the major features is it is read/write. The most common, but by no means the complete list of things that you access with directory access is users, groups, and mount records. We also do the password verification for the system.

So anytime you guys type a password in the login window or log on over SSH, those processes are calling directory services to verify the password. Lib system APIs, for those of you who are familiar with Unix programming or POSIX programming, get PWNAM, get GRNAM, all of those calls are handled by a process in the system called LookUpD, which is tied into directory services. And as of Tiger, as I said, we introduced MemberD, which is the group resolution engine for the entire operating system.

The major support MemberD brought to the equation was nested group support and support for more than 16 groups, which was no small trick in the Tiger timeframe. So what is directory services in 10.4? It includes an LDAPv3 read/write plugin, Active Directory, a NetInfo plugin, NIS/Etsy, service discovery plugins, the finder uses directory services to do all the network browsing under /network. It's a documented access API and plugin API.

The SDKs are posted on the developer website. There's a header installed in system library frameworks. And there's command line tools like DSCL, which stands for Directory Service Command Line, DSEdit Group, DSImport, Password Policy, PassWD. These are all directory services. So we're going to go ahead and get started. So let's get started.

This is the closest of a simplified architectural diagram. You have the legacy command line products or Unix tools running, and they typically go through the lib system APIs. Those dispatch to LookupD. LookupD has its own cache, and it will call out to directory services if it can't find the data, and then directory services will consult the plugins.

Some of the applications call directory services directly. In that case, they're still consulting the same data source, so this is how we keep the two worlds seeing the same set of users and groups. If they go through the legacy Unix APIs, they hit LookupD, which calls directory services. If they go through the new APIs, they hit directory services, which consults the same databases.

So that's the client side. There's also a server side to the directory services, which is if you don't have a directory system already deployed, how do you deploy one? Well, Mac OS X4 includes a full directory server. It includes Kerbero, it includes a password server. It's a full authentication replicated scalable directory system. It's based on LDAPv3. I believe the release that we're based on is OpenLDAP 2.2.19. This directory server supports 10.2, 10.3, and 10.4.

And we have an enhanced password server. The password server is one of the most confusing parts of this. People want to know why we have it if we have Kerbero. Well, Kerbero doesn't support legacy authentication methods like NTLM or NTLMv2. So the password server bridges the gap for the things that Kerbero doesn't do, the password server does do. And we keep those two password databases in sync. The password server itself on the wire is based on Sassl. If you actually look at a password server exchange, it looks like NTLMv2. It's based on any other Sassl exchange.

And the password server also does all the policy enforcement. So if you want an account to expire on June 30th or anything like that, the password server enforces all of those sorts of features. We have a fully integrated Kerbero server with only minor modifications for the password server synchronization. Other than that, it's a vanilla Kerbero server that we get from MIT. And we support Windows clients via PDC and BDC integration using Samba.

Whenever Samba gets a PDC request, it forwards it to Open Directory. So you create a user record in Open Directory. If you have a PDC configured, that user record is also visible on a Windows client. So your users can log on to a Windows machine with a name and password, or they can log on to a Mac with the same name and password. They change it on one platform, it automatically gets changed on the other platform. Keeps the two worlds in sync. And we support secure replication for LDAP and authentication data. So we think we have a fairly scalable directory server. It's very complete and feature set.

And so far, it has met many, many of our customers' needs. And I hear about new ones every day. One of the innovations we added to Tiger was a directory-based schema. For those of you who have administered LDAP, if you have multiple replicas, the way to add schema to the LDAP server is to edit the config file.

Well, that works really well on one server. But what if you have 30 servers? Well, you have to go visit each 30 server's config files and update them manually. Wouldn't it be cool if you could just put the schema in the directory and let the replication replicate the schema out to the replicas? Well, that's what we did in Tiger.

And that changed open LDAP is open source and has been posted on the Darwin website. And we support up to 200,000 records in the directory system. I know some of you have more than 200,000 records, but this meets a large, large majority of our customer requirements. There are very few people that need more than 200,000 user records in a directory system.

So in summary, Mac OS X comes with Open Directory and Tiger and has always come with Open Directory since 10.0. The client and the server are fairly complete and offer a very compelling solution for deploying managed networks, maintaining your client workstations, and having central command and authority. We're based on industry standards. We're using LDAP. We're using Kerbero. We're using Sassl for our authentication. There's no secrets here. The vast majority of Open Directory is open source, and we fit in with existing directory deployments. So if you already have a working directory system, there's a high probability.

There's a high probability that you'll be able to configure Mac OS X to work with that existing directory system. Directory services works below most of the application and is transparent to the vast majority of the system. And Tiger saw a major upgrade with our enhanced group support. So that brings you up to date on where we are with directory services today in the Tiger that you have running on your desktops. How many people have installed Leopard on their notebooks and are running it right now? Oh, wow, that's a lot. So you're running directory service on Leopard. For those of you that haven't, you're using the Tiger directory system. So now we're going to talk about Leopard.

So what are we doing with directory services for Leopard? Well, we're doing a lot. We're going to have a major architectural overhaul that I'm going to talk about later. We're making changes to the local configuration database. We'll be talking about improvements in the Active Directory plugin. And we'll be talking about server enhancements that we have planned for the server.

This is the standard architectural diagram that I've been giving for about the past six or seven years. This is a simplified view. I believe it's highly accurate. However, like any diagram or any graphic, it's simpler than it needs to be. And for purposes of the conversation we're about to have, I'm going to have to pull back the covers a little bit and show you a little bit more about what's going on underneath the covers. So we're going to swap out that architectural diagram for that architectural diagram. And the two changes are the lib system APIs on the left and the DS APIs on the right. Below that is a cooperation among three different daemons in the system.

If you run tiger and you run top, you'll see member D directory services and lookup D running in the process list. Those three daemons cooperate with each other to provide the system with all of the directory information it requires. And then beneath all of that are the plugins that provide access to the different data sources. So lookup D handles lib system. It caches results so that if an application is launched and calls get PWNAM over and over and over again, it's not actually doing I/O on the network or on the disk. It's reading it out of lookup D's cache.

Does the DNS resolution for the system. If you resolve a host name through Safari, that call ultimately hits lookup D and lookup D does the host name resolution. So lookup D is the one that's going to be the host name for the system. And it accesses the local database.

It uses directory service for network access. So if lookup D can't find the user record in the local database, it fails over to directory services and says, "Hey, directory services, can you find this user record?" And if you have an LDAP server configured and the user record actually exists, directory services will hand the result to lookup D and magic will happen. Member D handles group resolution.

So when the kernel encounters a JPEG on disk and the user record is not in the directory, it's going to be a group resolution. So if the user record doesn't match the permission and there's groups on the permission list, the kernel will call member D and say, "Is this user a member of that group?" Member D is responsible for caching the answer and if it doesn't have the answer in cache, it's responsible for getting an answer for the kernel. So that's a critical part of the system and it does groups result caching because the kernel asks about the same group memberships quite a bit.

I think on boot it asks about, "Are you a member of wheel?" like over 2,000 times. So caching is very important. And then directory services. So the directory services provides access to the network directories, NIS. It provides access to LDAP and provides access to Active Directory or any other plugin that you've written or installed.

There's always been some redundancy in these daemons. Lookupd does some work that then if it can't handle it, Directory Services does the same work over because it doesn't know if it's being called by Lookupd or being called by login window. There's been some redundancy in this architecture. Engineers don't like redundancy. We're going to clean it up. So our goals for Leopard are to actually have this architecture diagram be enormously accurate. There's only one Damon in the system.

So the lib system APIs on Leopard that you're running, dispatched today directly to directory services. If you run the process list, you will note lookupd is not running in the tiger seed or the leopard seed that we gave you. The DS API is still dispatched to directory services and for Leopard GM, MemberD will not be running. MemberD is still running.

It was too much risk to put into the WWDC build, but we've got it prototyped. It's working. So directory services is consolidating all of the directory daemons into one daemon. So a single directory services daemon to handle lib system, a single directory services daemon that does caching, local data access, and DNS host resolution is all done out of directory services now.

Less IPC dispatch. Those lines that I gave you on the architecture diagram earlier, every time you saw a gray arrow going one, that's a Mach IPC. And while Mach IPC is enormously high performance, anyone who programs in the audience knows the fewer procedure calls or system calls you can make, the better. This is fewer system calls, and it will be a saved memory footprint of three fewer daemons. So lookupd and memberd will not be running in the GM version of Leopard. Leopard already, with the build you have, does not have lookupd running.

So, where are we at? The WWDC build of Leopard has no LookupD running. Go ahead, check. You can run top or PS. All lib system API calls now dispatch to directory services. And this is kind of fun. I'm walking down the hall, and the question I get the most is, hey, Dave, what are all of those lib system calls that LookupD handles? That's exactly what everyone's most interested in. Aqua, high DPI, calendaring. No one cares about that. They want to know what lib system calls that LookupD used to handle.

Well, I compiled a list with the help of my engineers, and there they are. So, these calls have always, even prior to Cheetah 10.0, these calls were always handled by LookupD. So, all we did was take the implementation that already existed and redirected all these calls to talk directly to directory services.

So, that's been done. So, if you call any of these calls in your code, directly or indirectly, you're now using directory services goodness. And when Leopard ships, memberd will be subsumed by directory services as well. And the memberd APIs are only one or two to ask about membership, and they're in membership.h, which is in lib system.

And that leaves one other daemon running. For those of you who are very, very savvy about Mac OS X, you know that Mac OS X, even when not bound to a network directory, still has a local directory server running for your local database. That local directory is lovingly referred to as NetInfo, and there's a daemon running on this system called NetInfoD, which brokers access to the local NetInfo database. We're getting rid of NetInfo.

So even on a local Tiger system with no network access, there's an extra daemon running. So NetInfo has been the historical local database, and it works like this. Local data, talk to NetInfo. So the local data plug-in and directory services talk to NetInfoD, and NetInfoD access to file on disk at var db netinfo slash nidb dot local. For those of you who want to do a clean install of your operating system, please delete this file right now, and you can wipe the hard drive because that deletes your local admin user and everything else. I'm just kidding. Don't do that.

NetInfoD also handled remote access. So this is how directory services got--for those of you who know a little bit about NetInfo, NetInfo was both a local database and a remote database. It could be run across the network. Well, the daemon that accessed the remote database was also NetInfoD.

So NetInfoD was responsible for both local data access and it's responsible for network data access. Now, we have not supported deploying a NetInfo server since--is 10.2 Jaguar? Yeah, okay. Since Jaguar. So we haven't encouraged people to deploy more NetInfo servers, but we haven't yet gotten--but we hadn't yet gotten rid of the local NetInfo server.

NetInfo could hold about 10,000 entries. It could store string data but not binary data. It had write access controls but no read access controls. It was a pretty good directory system, but--but we didn't like the extra IPC dispatch even for local data access. So local access was handled by a separate RPC-based daemon. RPC has some issues. If you think about it, NetInfo is actually based on RPC for those of you who've looked at the source.

And it's based on SunRPC which requires the networking stack. And there's some very interesting deadlock conditions in boot time and when you're waking from sleep and all that sort of stuff that the networking stack's not even ready to handle loopback. So having an extra IPC dispatch led to some very hairy programming problems that during very narrow windows of time, NetInfoD may not have been responsive to local calls even for accessing the local database. And it's another moving part. And again, for the engineers in the audience, more moving parts is more risk, more complexity. So we're removing this moving part from the system for local access. So we're, as of Leopard, retiring NetInfo.

This is its jersey. So if any of you have NetInfo deployed at your site, Now would be a really good time to upgrade to Open Directory. I want to emphasize this. We will not even legacy support this. We're not saying that this is going away and we're not doing any more enhancements. We are yanking this from the system. There will be no Net Info support in Leopard at all.

So the local data store replacement, this is a question I get a lot. So now the local database for store will be in var db dslocal nodes default, and underneath there, there will be one folder per record type. Under default, you'll see users, groups, and mounts, and underneath each one of those, you'll see one file per record.

The file format will be a plist. So if you want to edit this plist while you're in single user mode, go ahead. It's just going to be a plist, no tools required. So it's being replaced with a local implementation. Records are plists. It can store string and binary data in the local records.

This is being used, by the way, by login window and system accounts prefs to put the user picture into the user record in the system and some other nifty little integration points. This is one less daemon running in the system. NetInfoD will no longer be running. And to access a local database, there's no longer an IPC required to talk to the database.

This is a huge win in complexity, reduces footprint, and makes the system more reliable overall. All local NetInfo data. So if you have an existing NetInfo database, we will of course migrate all of the data out of the local NetInfo database and into the new database. Network NetInfo will not be supported in Leopard.

LDAP, Active Directory, and NIST, we think, cover the network directory access needs pretty well. So if you need a network directory system, you can pick any one of these threes. We highly recommend LDAP and Open Directory. NetInfo Manager and all the NetInfo tools will be removed from NetInfo or from Leopard. There are several scripts that we've developed internally at Apple, and I'm sure you as well have used Nickel or some other NetInfo tools. Now is a really good time to migrate those scripts onto the DS tools.

The DS tools have been present in the system since Jaguar with them getting more tools in every build, so there's really nothing preventing you from going ahead and moving away from Nickel, for example, if you're using that. In Tiger, you can do that today and use DSCL instead of Nickel. The change is transparent to 99% of the system software. Because we have so many abstraction layers, login window doesn't even know that there's not a local NetInfo database, nor should it.

So what tools should I use instead of the NI tools that I've used historically? So legacy tools, Nickel, you can use DSCL. That's been there since 10.3. NI Load, you can use DS Import, which has been there since Jaguar. NI Dump, you can use DS Export, which is new in Leopard. There's a man page. NetInfo Manager. Who has Leopard installed? Again, if you right click on a user account in System Accounts Press, you can now edit the user record for UID, Home Directory, Path, and other things. I have a screenshot of that later.

If you need to edit groups on the local system, you can use DS Edit Group, which has been there since Tiger. If you need to edit mount records, the new directory utility has a mount record editor for adding local mounts to access Linux, NFS servers, or otherwise. And if you need to enable root, there's always been the command line tool, DS Enable Root, or you can go to directory utility under the edit menu, and there's an Enable Root command there as well.

So we think we've covered most of the legacy usage of any NI-based tools, and so you should get off of those tools as soon as possible. Except for DS Export, all of these tools are in Tiger. So you can move your scripts, your internal deployments, anything that you've already got can already be moved to these new replacements today without waiting for Leopard, and then you're prepared for the future.

So, account system preferences. If you right-click on a user record in account system preference, we get this nifty pop-up called Advanced Options. The HI people wouldn't let us have an actual button, so it has to be hidden. So you right-click on the user record and this sheet pops down. And you can edit all the things most people needed to launch NetInfoManager to edit previously.

So you can edit the UID, you can edit the group ID, you can edit the record name, you can edit the login shell. You know, anything that you typically would have had to have launched NetInfoManager to do in the past can now be done directly from within the system accounts preference. There's even some nifty support for this. If you're home directory, if you hit Choose on the home directory, you can actually point it at an encrypted file vault and reset your user record up to point to a file vault.

Director Utility is, we renamed it Utility because it no longer just manages access, it also now has some utility functions. Under the Edit menu, we have Enable Root. And if you look carefully in the toolbar, you'll see an icon there called Mounts. That's so you can add and remove mount records to the local database.

For those of you who know anything about NFS, there has to be a mount record for Mac OS X to recognize an NFS server. And previously, the only way to teach Mac OS X about a mount record was to put it in LDAP or use NetInfoManager to put it in the local NetInfo database. NetInfoManager's gone. How do I add mount records? Well, we put an HI in Directory Utility for you.

So now I can complete the timeline. So now we've got what Jaguar looked like, what Panther looked like, what Tiger looked like, and the new functionality for Leopard is DSLocal. We'll be talking about Active Directory with packet signing, and we have some new administration tools. What's important about this slide is not what's new, but what's missing. LookupD is gone, MemberD is gone, NetInfo is gone between Tiger and Leopard. So this is your future. This is the way Leopard is going to ship. If you have any questions or anything like that, we'll be happy to answer them at the end of the presentation.

So architectural summary. Directory services, lookupd, memberd are merging. This simplifies the system, reduces daemon count. There's all sorts of goodness coming out of this. Netinfo is no longer supported. I hope you get that message. Netinfo is not supported. It is still in the build. We had some engineering difficulties. And for risk management, it's not in the build.

So please, please, please don't take the fact that your Leopard preview still works with Netinfo to be a contradiction of this presentation. This presentation's the truth. What you have is a pre-release. We've also removed Bonjour, SLP, SMB, and the Apple Talk plug-ins. This functionality is going to be picked up with a direct browser in the finder, and that's all I can say about that at this time. Leopard Directory server.

So for Leopard, we're very excited about the changes we've made to Open Directory. The directory services architecture in Tiger is leaner, or in Leopard, is leaner, meaner, and faster than it's ever been. And we hope to get a lot better mobility support, more reliability, and to make your administrative lives easier by getting rid of one outdated networking protocol.

So if you're using the NetInfo command line tools, you've got to get off of those right away. We don't see any reason that you couldn't do that today in Tiger. And for the things that are missing, we've added those in Leopard. If you have any software that calls the NetInfo APIs, well, those have been deprecated since 10.2. So if you didn't get the message when there were compiler errors in Xcode, now's a really good time to stop using the NetInfo APIs. And if you have any internal scripts that use Nickel, move them to DSCL.

So what are we doing for Active Directory? Well, this is another exciting plugin. We introduced that in Panther, and we've provided some enhancements in Tiger. Namely, we added support to the Active Directory plugin to support MemberD, so we could get nested groups out of Active Directory. But we weren't done with Active Directory, and I think we're going to catch up and make a lot of you happy with the Leopard feature set in the Active Directory plugin. So Active Directory is a very popular configuration. Surprisingly, it's used by about 40% of our customer sites.

And so for Leopard, we're improving the replica and site support. There's been some feedback that we don't always pick the same replica as a Windows machine would have, so we're going to improve that and try to behave more like a Windows client would in a similar situation. And we're going to support packet signing.

For those of you who don't know, there is a lockdown mode that you can deploy Active Directory to require full packet signing that every transaction with AD is authenticated and authorized and signed. We haven't supported that, and if you attend the SMB session, which is going to be in the next few weeks, we're going to be able to do that.

So if you're watching this video and you're not sure what's going on right now next to me, you will find out that we're adding packet signing to the SMB file protocol. So now that we have it in the file client, it makes sense to add it to the Active Directory client, so we're supporting packet signing in Leopard with the Active Directory plugin.

So this will make, we hope this will make Mac OS X a first class citizen of Active Directory networks and will support all the security options that you can set up on Active Directory. Currently to allow Mac OS X machine to join your network, you've had to lower some of the security settings on Active Directory and nobody likes that, so we're fixing that.

Server improvements. We're doing a lot of work on the server for Leopard. Directory services is a never-ending well of work for me and my team. My management doesn't like that. I do. It's kind of job security, but we are putting some attention into the server for this release. So, first thing we're doing is upgrading to OpenLDAP 2.3.x. I say .x because I don't know what version OpenLDAP is going to be at in spring of 2007, but it will be the latest version that we can reasonably ship and qualify.

We're merging all of Apple's diffs to overlays. This should make it far easier for those of you who want to download a later version of OpenLDAP and still get all of Apple's diffs applied for updating. We received some feedback. While we've posted all of our source changes, prior to OpenLDAP 2.2, there was no way to add plug-ins or overlays to OpenLDAP without invading the source, and some of our changes were somewhat source invasive.

We received feedback from customers in the OpenLDAP community that we can now use the overlay technology to deploy a lot of the data. Like the directory-based schema can be done as an overlay. So, we're moving all of our changes to an overlay, which means you can download a baseline OpenLDAP and just add Apple's overlays without changing the source code or doing a source code merge.

So, this will make it easier for you to keep up to date with a newer version of OpenLDAP and make it easier for us to keep up to date with a newer OpenLDAP. Those of you who have attended the calendar or Teams presentation, what do you think of that technology? Is it good stuff? Thank you.

I'm very excited about it. The directory services team has been involved in a lot of the planning, and that doesn't come for free without some directory services changes. So there's a number of changes coming in Open Directory to support Teams and to support the calendar and the Teams directory. Some of these changes are schema and access control improvements and granular access controls. There will now be choices other than directory administrator and nobody. You'll be able to have granular settings in the directory system.

We're also introducing replication scale improvement. For those of you who know about our current design, it's a hub-and-spoke model. You've got the master at the center and you line up replicas around it, and they all beat on the master to try to get as much data as they can out of it. Well, we all know that doesn't scale, and we're going to address that. So the new design we're calling cascading replication, and this will allow us to have 32 replicas of a master and 32 replicas of each replica.

By my math, 32 times 32 is 1024, and so that will allow 1,025 replicas in a two-tier hierarchy to be deployed. We think this is a substantial scale improvement. It allows you to guide your network topologies, look for it, plan for it, because for those of you who currently have more than 32 replicas deployed, you're going to have to restructure those into a tree or a cascading architecture. But this should allow us to deploy many, many more directory servers than we've previously been able to effectively support.

The next feature I'm very excited about is airport base station support. How many of you have wireless networks? How many of you would like to be able to use your Open Directory name and passwords to access those wireless networks? The Leopard server that you have in your hands can do that today. We support Radius, and so does the airport base station.

So Mac OS X server has a Radius server included with it now, and you can configure free Radius on Mac OS X, and we did a very, very simple thing. We took free Radius and we wrote a plug-in for it, and every time it receives a name and password, it forwards it to Open Directory. Once Open Directory has verified the password, free Radius tells the base station to let the user log in.

Nothing more than that, nothing less than that. So we have full airport base station support. The Radius server can handle multiple base stations. We're currently living on it at work. We have three base stations joined to it. We're doing some scale testing. It should easily handle 50 to 100 base stations on a single Radius server. This allows users to authenticate on your wireless network with their Open Directory name and password. This uses WAP2 Enterprise Authentication 802.1 uppercase X, please, because lowercase x.

It's a little different standard. And so we use WAP2 and 802.1x authentication, and the Airport Express and Airport Extreme already support this standard. There are no firmware upgrades required at the airport. It just works. The RADIUS server is based on Free RADIUS and all of our modifications will be posted to the Darwin website, if they haven't been already. I'm not sure what the... Steve, have we posted our mods on Darwin yet? No.

So in summary, Open Directory is Mac OS X's configuration infrastructure. We support both local and remote management of common system configuration information. We have an architectural overhaul coming for Leopard, major changes in the local directory infrastructure. Local and network net info will no longer be supported. We're improving the Active Directory plugin.

And we have several enhancements for the Open Directory server. We have team services support. These are mostly boiled down to schema and access control changes. We're moving to a new version of OpenLDAP along with the migration of our diffs to overlays instead of straight diffs to the baseline source.

We're improving replication scale and we support airport base stations via free RADIUS integration for this particular release. Again, I encourage you to play with the RADIUS server that you have in your Leopard preview. It has access control support. You can control who can access which base station and so on and so forth. It's a fantastic product. We're very excited about it. For more information, you can contact Skip Levens. He's the technology evangelist, and there is documentation and sample code at the standard websites.