My name is David O'Rourke. I'm the engineering manager of Open Directory. I have to get my little cue here. How many people were at last year's presentation? Could you raise your hand? How many people actually had a seat at last year's presentation? Very few. So they moved us to a bigger room.

So I want to thank you all for overflowing last year's presentation. Next year I'm going to go for the pool in the open bar. How does that sound? David O' Okay. Also, I'd like you to all go out in the hallway and get a friend. I'd like to pack this room so we get in the big one upstairs. No. Okay. I think I would actually be scared of that many people.

My name's David O'Rourke. We're here to talk about Open Directory, what it is, what is Directory Services. We're going to review Directory Services for 10.2 for those of you who are new this year. We're going to talk about our future plans for Panther and then we're going to go into Q&A. So, I guess now is as good a time as any to get into it.

So, first of all, Open Direct - last year we introduced the Open Directory technology name. And what Open Directory is, is a technology umbrella, kind of like QuickTime. It covers a lot of different technologies. In our case, it covers the client access technology and also covers any servers that we deliver as part of the Panther Server product.

Apple's strategy in the Open Directory space is to adopt and promote industry standard technologies such as LDAP, Kerberos, Sassl, whatever directory related technology fits our purpose. We're going to adopt it, embrace it, and promote it on our platforms. So, Open Directory is built into both Mac OS X desktop and the client's built in, and it's built into Mac OS X server. If you buy Mac OS X server and turn on a directory server, you get Open Directory. It's been there since 10.0.

And the good news is, is everything we do is open source as part of Darwin. So, no secrets. You can review our implementation, see if it meets your needs, see if we're sometimes passing a password on the wire in the clear. But we try to fix bugs like that, and you can see it in our source code.

The directory service history, we started out with Mac OS X 10.0 having NetInfo and LDAPv2 as a client. We then, in 10.1, introduced... : We introduced a desktop server with LDAPv2 support. In 10.2, we introduced NetInfo, LDAPv2, LDAPv3. We added NIS and flat file support or Yellow Pages. Is NIS the proper name these days or is it Yellow Pages? NIS, thank you.

We also introduced service discovery based on directory services. So we have an AppleTalk plugin for browsing AppleTalk networks. We have an SLP plugin. We have a rendezvous plugin and we have a plugin for browsing Windows networks. So if you see a Windows server when you go to connect a server in Jaguar or slash network on Panther, you're using directory services. Panther's even better. It has all the features of 10.2 and we're going to go over some of the new and exciting features right now.

First I want to talk about what Directory Services is. This is the client access portion of the product. It's a standard box diagram. Engineers like to draw boxes. I'm an engineer so I drew some boxes. We've got Mac OS X software running on top of an abstraction API. We've got the abstraction API there in the middle in the blue box. Is it blue on your screen? Yes it is. At the bottom layer we have plugins.

We have a plugin for NetInfo, we have a plugin for LDAP, we now have a plugin for Active Directory, we have a plugin for BSD files, and you as a third party can develop your own plugin. I believe we're still working with somebody to develop an Oracle plugin so that their directory system can be an Oracle database.

Directory services in 10.2 included an LDAPv3 read/write plugin, an LDAPv2 read-only plugin. It included NetInfo. It includes NIS, BSD/SE files. It includes service discovery. The APIs are documented and the plugin APIs are documented. We have an SDK. It includes sample code. We have sample plugins. We have a stub plugin that you could adopt and put your code in. Or you could start with our own productized LDAPv3 plugin and gut it and use it for your own purposes. And the directory services headers are installed in system/library/frameworks/directory-s ervices/framework.

How does 10.2 use Directory Services? This is a question we're kind of plumbing. If we're doing our job right, you don't even notice that Directory Services is working. My management keeps asking me to demo it, and I say, "Did you make it past login window?" And they say, "Yes." I said, "That's the demo." It's a really boring demo, but if we're doing our jobs right, you don't really see Directory Services because we're just feeding config information to the system behind the scenes.

But Managed Desktop. How many of you use Managed Desktop? Managed Desktop sources all of its information out of Directory Services, so that's one key consumer of the data. All the security framework authentication, whenever that dialog comes up and asks you to type a password, they ultimately call Directory Services to verify that password.

And all the legacy tools have been migrated to PAM, so if you have PassWD or some password authenticating tool that's running on the command line, it calls a PAM module, and that PAM module calls either Security Framework or Directory Services, and that authenticates your legacy UNIX tools. And all the Mac OS X Server processes. Server processes and administration tools use directory services.

Connect to Server, Command-K in the Finder brings up Connect to Server. Everything on the left, all those zones and everything, those are all coming from either an Apple Talk, SLP, or Rendezvous plugin when you click on the zones. So all the service discovery in Mac OS X, slash network, how many of you have played with the new slash networking feature in Panther that allows you to browse? That's now all sourcing the same information that what we call NSL, or Connect to Server, was sourcing in 10.2.

And you can use directory access as a system administrator to turn off the browsing of certain protocols. So if you don't want your customers ever connecting to your Apple servers over Apple Talk, you can turn off their browsing by going to directory access, turn off the Apple Talk browsing plugin, and then Apple Talk zones will no longer show up and connect to server. That does not turn off the Apple Talk protocol, it just turns off the browsing portion.

Another way Mac OS X-2 uses directory services - this is an architecture diagram. Next came to us with Next Step and they had already hooked a lot of the BSD routines to extract their directory access through a process called LookupD. And so the system is really - the system is a bit schizophrenic.

There's the legacy APIs that access directory data and there's the new APIs that access directory data. The way we make both systems regardless of which API get the same data is anything that calls LookupD, we have a plugin in LookupD that shunts the request over to directory services.

Anybody that's calling directory services, they of course get what directory services is configured. So this means when you configure directory access and add an LDAP plugin to your search node, you're also configuring what the entire system sees on the command line side. How it resolves users, how it resolves groups. So this is the real power of the system. So even though there's two different APIs, they all work together. Even though there's two different APIs, they always return the same set of data because they're linked.

Mac OS X/2 Server includes two choices. This is Jaguar Server. I want to emphasize that we're going over history, so not the future. X/2 Server included two choices for a directory server. You could deploy NetInfo, which was always supported. That supports Mac OS 10.1 and 10.2. We added, for the first time, an LDAP v3 plugin, but it uses the NetInfo database for its backend. So when you create a record through NetInfo, it also showed up on the LDAP side. Luke Howard did that work for us from Paddle. He's in the audience today.

I'd like to thank him for that. It's really kind of cool because you can source your data from one database and serve it up over the NetInfo protocol, serve it up over LDAP. It supports the Mac OS X/2 clients. And we introduced the Open Directory password server, which is the SASSL-based network authentication for legacy authentication protocols.

I highly recommend that you go back in time and go to yesterday's auth session because we talked in detail about the password server. You can go back in time. I believe we have these sessions available on DVD later. Is that correct? Can anyone confirm that? So if you didn't catch the auth session and want more details, work with Apple Developer Relations to get this year's presentation.

So on 10.2 we made a lot of progress in the directory space. We added NL.v3 server, we added service discovery, and we introduced new authentication methods with the password server and the authentication authority and that's all the product that we're all using today. What I want to talk about now is what we're planning to do for directory services this year.

And so we're going to move into directory services for Panther. The first thing we're doing is we're substantially enhancing the LDAPv3 plugin. I'll get into the details of that. We're substantially enhancing the Open Directory password server. We combined the NIS and flat file plugin. In Jaguar they were two separate plugins. What we've done in Panther is we've combined them into the same source set and just taught them to share information. We're getting rid of the LDAPv2 plugin. We're enhancing support for Active Directory and we're making changes to local authentication.

In addition, we're enhancing the SMB Windows Network plugin. We can now browse off of a local subnet. Slash network is now based on NSL, which was the Mac OS 9 network service location protocol slash directory services. We've added man pages for directory services and we're going to be demoing some new command line tools later in this presentation. And we've made some minor changes for plugin developers.

So if you're developing a plugin, there's some gotchas and some heads up that we need to keep you informed of. LDAP v3 client enhancements. This is the meat of the work we're doing for Panther. In 10.2, LDAP v3 was already very robust and could talk to a lot of different LDAP servers. We supported DHCP LDAP discovery through option 95. We supported storing our configurations or our mappings on the LDAP server itself so you didn't have to visit each machine to reconfigure it.

We integrated support for the Open Directory password server so that LDAP would use the password server when the authentication authority and the user record told us to. So what we're doing for - For v3 and Panthers, we're adding replication support. So you can deploy multiple LDAP servers and our v3 plugin will fail over.

There will be client side awareness of LDAP replicas and if you're using the DS APIs, the failover is completely transparent to you so you don't have to do anything. You just call Open Directory, say "Open DuraNode, I want to talk to an LDAP server." That LDAP server goes away, we have to find a replica, your code keeps churning along, it doesn't even know that we've switched network connections.

LDAP V3 client replica picking is quite thorough. We'll automatically detect and use LDAP replicas. We will use any or all of three replica discovery mechanisms. There's an existing standard for LDAP called Alt Servers, which is stored in the root of the LDAP server. If we find that information, we will use the LDAP replicas that are stored in that information. We are adding a new record to the LDAP system that we call a configuration record.

That configuration record is no harder than a list of IP addresses. It has to be well named. There will be documentation and server admin. But if that configuration is found and lists IP addresses for us to contact, we will use that record. So you can actually put the replication table in the LDAP server and we'll use it. And there is an LDAP replication scheme for DNS service records. So if you've configured DNS to list multiple LDAP servers, we'll use DNS service records.

All of these methods require LDAP server connectivity at least once. We can't come up. So if you call us an IP address as the LDAP server that you want us to talk to and that isn't even reachable, we can't discover the replicas. So we require connectivity to the LDAP server at least once to harvest all of these sources of information. But after that, you can move the LDAP servers around willy-nilly.

And as long as one is still up and running, we'll contact it and learn about the new information. We put the failover support in the client because now Mac OS X server LDAP supports replication. And clearly we're going to work with that very well. So now that we have a replicated LDAP server, we needed a replication.

We needed a replication-aware client, and we've done that in Panther. Replica failover resolution is done in parallel. We will not serially try 20 LDAP servers at two minutes a shot and make the user wait 40 minutes to find the replica. We try to do the discovery in parallel.

We also try to do it in such a manner that we don't spam the network on every single open attempt. We try to gradually build. We get more and more aggressive over time when the LDAP servers are nonresponsive. So we won't bring up unnecessary network connections if the LDAP server is just a little slow to respond. But if it's too slow to respond, we'll start looking for replicas and that will cause more networking traffic.

We've also enhanced the password server. New authentication methods - we have some authentication methods to support the new VPN server, and we support PDC authentication. The PDC needs certain authentication methods to be able to authenticate Windows clients, so we've had to add authentication methods to the password server to support that. We've added new password policies. We have global and per user policies. I went over these in detail in the authentication session.

And we have secure replication. We have true multi-master replication. Every single password server replica can accept a password change. We have client-side failover, so if one password server stops responding, we use other password servers. There are more details in session 607, which was yesterday's session. But it is secure, and it is multi-master replication.

Here's a screenshot of the global policies. This is a new HI for Panther, so we support a number of policies. I won't go into them in detail right now, but I'll leave it up there just for a bit so you can look for your favorite feature. I have heard dictionary is not here though, so everybody wants dictionary and we're going to look into that.

The authentication methods that the password server supports are MD5 digest, which is used by default. If you don't specify an authentication method, this is what login window uses. And if any DS API client requests clear text authentication, we actually turn around and do an MD5 authentication behind the scenes. Kram MD5 is typically used by IMAP and SMTP. We have NT and LAN Manager that's used by SMB file sharing.

We support APOP, which is used by the POP3 mail protocol. We support WebDAV Digest for WebDAV Apache modules. The new authentication method we've added is MSCHAP2, and that supports the VPN technologies. We are retiring two-way random in the Panther timeframe. Jaguar supports it, Panther won't. No. Not a lot of AFP clients are still using it. If you are still running on an AFP client that requires two-way random, I think we have AFP clients that are qualified all the way back to 8.1. Leland? Yes.

8.1 that do DHX, which is the last authentication method that we support. So all the way back to Mac OS 8, you have an AFP client that doesn't need to a random, so we're getting rid of that. The authentication authority matrix. The authentication authority was introduced in Jaguar. It's an attribute in the user record that indicates to Jaguar how the user record should be authenticated if an authentication is attempted. We had several values. We had basic last year, and that basically indicates the user's crypt-based.

We introduced the Apple password server authentication authority. This indicates that the user's password server based, and in that authority is all the information we need to know to contact the password server and verify that user. This year we're introducing ShadowHash. Local users no longer have a readable crypt password on Panther. For those of you who go rummaging around with niDump on your Panther machine looking for your crypt password, it isn't there anymore.

So ShadowHash is indicated. ShadowHash indicates that this user record is ShadowHash based instead of local crypt based. And we're introducing the Kerberos auth authority. How many people haven't heard we're making a big push around Kerberos? Okay. So we're going to indicate that users are Kerberos based by actually putting a Kerberos authentication authority in the user record. And that helps us know that we should attempt to do Kerberos authentication.

So local authentication changes. Crypt is dead. The default local authentication is stored in a shadow file for all local users. Crypt is still supported, but none of the Mac OS X tools will create a crypt user. If you want to do it yourself through DS APIs or legacy tools, it still works. It will still function. The OS will still verify the user's password, but none of our administration tools will create a crypt user.

Um, your application should not be relying on crypt passwords. Um, Panther will break any application that has not adopted security framework directory services or PAM or some other password verification abstraction API. This is not a bug in the operating system. In order to make the OS more secure and move forward, we have to break this. So if you have an application that is doing authentication and you're calling getPWNAM or some other API that returns a crypt password and you're relying on that to behave in Panther, it will break.

And we're not going to fix it because it's a security problem. So we need you to adopt a password verification abstraction. There are three major abstractions you can adopt. You can adopt PAM, which is a cross-platform, pluggable authentication method for Linux. You can adopt the security framework to do your password verification in your application.

If you need to do authentication, you should probably be seriously looking at the authorization framework because that's probably the more appropriate way for a GUI application to go forward. Or you can use the down-and-dirty directory service API and do the authentication yourself. I want to emphasize, if your application is not using one of these APIs, it will break when running on Panther. You will not be able to authenticate your user records. This is if you're a server, a client process, whatever. And just for emphasis and with color... So, we've gotten rid of Crypt. Sorry about breaking your app, but it's a necessary evil.

So here's a quick timeline of password server histories and future. We had Crypt in 10.0. We supported Crypt and LDAP/Bind in 10.1. We support Crypt, LDAP/Bind, Kerberos, the DS APIs, password server PAM and security framework in 10.2. We've gotten rid of Crypt support in Panther. We now support LDAP/Bind, Kerberos, DS API, password server PAM and security framework. And moving out into the future, Kerberos is going to - its font is going to get bigger and it's going to get a more impressive color.

So, authentication long-term. Apple's investing heavily in Kerberos. This means if we're investing heavily in Kerberos, so should you, either as a customer or as a developer. We are aggressively, aggressively migrating all of our networking products to be Kerberos-based. If there's a favorite protocol of yours that does authentication, and we ship a client and we ship a server, we're probably going to Kerberize it. We will ship the MIT KDC.

We already shipped the MIT Kerberos client, and sessions 607 and 108 are must-attends for any network service people. 108 is the Kerberos session done by Marshall Vail and his team. All Kerberos, all the time, is in Apple's future and yours. So, get used to it. Plan for next year's presentation.

We combine the NIS and flat file plugin. Mac OS 10.2.5 added an NIS plugin. Mac OS 10.2 supports /etc/config files. Panther's implementation combines the NIS flat file support into a single code base. And now there's a unified configuration HI. So it's really easy to configure this. This is the configuration HI. The BSD local doesn't require any configuration because we know where all the local files are. So that's just kind of there for documentation. And then the lower half of the configuration sheet is the domain name of your NIS server or list of alternative NIS servers.

And if you go to directory access, click on the NIS plugin. This is the configuration HI you're going to see. LDAPv2 is being retired. The LDAPv3 plugin has all the LDAPv2 features. LDAPv3 is more robust and has more features. LDAPv2 configurations will automatically be migrated when you upgrade to Panther for the first time. But - and so we're working to make that transition seamless.

But there's no reason for customers to continue to use v2. So you could move to LDAPv3 today on Jaguar. You don't need to continue using v2. So you can move ahead of us or you can wait for Panther to migrate your configuration file for you. But either way, the LDAPv2 plugin is going away.

We are providing an Active Directory plugin. This plugin is a native client of LDAP and Kerberos. We're holding Microsoft to their word that Active Directory is nothing more than an LDAP and Kerberos server. So we're holding them to that and we use nothing but Open LDAP and the Kerberos APIs to interact with Active Directory. We don't use any proprietary RPCs. No schema modifications are required to use this plugin.

The plugin generates any missing Mac OS X attributes. So we generate UIDs, we generate home locs, we generate all the missing Mac OS X attributes. We can't generate managed desktop data. I can't fabricate doc preferences out of thin air. So really this is a baseline level of compatibility with Active Directory. If you just want users to be able to log on, get their name and password and stuff like that, the AD plugin is an excellent thing. If you want to actually use some of the unique features of Mac OS X, you have to modify the AD schema and add the information we need. But that's above and beyond the baseline feature set.

So the Active Directory plugin supports all the AD features, supports the baseline AD schema, and still supports our extensions if they're present so that we can get additional feature set out of the AD plugin. It supports domain controllers, authentication policies, replication. All the features are there. Eric Clements has done the AD plugin for us. He's done a fantastic job. And we look forward to your feedback on the product. If Mac OS X data schema is present, this AD plugin will work with that as well.

This is the configuration. I don't think we could have made it much simpler. You don't need the advanced options most of the time. You enter the forest, the domain, you enter a computer ID, you hit bind. We create a computer record in the AD system. We use that computer record to bind to the Active Directory system. You then go to directory access and add the AD plugin to the search policy. You log out to logon window and you can log on as an AD user. That's it.

We do automatic multi-domain authentication. You can force us to use a particular server. You can force us to use a unique ID attribute that's present. You can cache the last user login for network disconnect. So when your users go home and they aren't connected to an AD system, they can still log on to their PowerBook with the same name and password they use for their network accounts. This feature... will be covered more at the mobile managed desktop session later today and is for any directory services plugin.

So if you have an LDAP user, if you have a crypt user or you have an NIS user, we now support offline caching of local - of network user records. And you can set up a number of groups for the AD plugin to administer - which AD user should be considered local administrators on this system.

So, we have service discovery in Panther. We still have AppleTalk, we still have SLP, we still have Rendezvous, and we still have SMB. We have rewritten the SMB plugin from scratch. It has the same functionality as Jaguar, but we can now browse off of subnets. That's the major feature. We still have Rendezvous, AppleTalk, and SLP.

SLP will be retired in a future OS release. I don't know when, maybe next year, maybe the year after. It will at least be made an optional install in a future OS. So, if you have any applications that are relying on SLP, I highly encourage you to move on to Rendezvous because Apple's going to start deprecating this service over the next few years.

We have some command line tools and man pages. We now have man pages for directory services. We have a suite of tools for directory services. We have DSCL, which stands for Directory Services Command Line. We have the PW Policy tool, which lets you, from the command line, set password policies on the password server.

PassWD now uses directory services. We have DSPerfMonitor and we have DSError, which will convert the numeric error codes to a display string. We have API profiling. We're going to demo that later. And we have server tools and Work Group Manager now includes a new feature called the Inspector. How many of you are used to ResEdit? Remember ResEdit from Mac OS 9 days? Inspector is ResEdit for directory services.

It's a raw editor. You can really shoot yourself in the foot. If you want to have a really good time, I really recommend you go into the Inspector, you mess with your home loc, you change the user's auth authority, and paste in a random string into the grip password.

You'll just have a great time with that. So the Inspector is a new feature and we think it's quite useful. We already use it internally to debug our GUIs. So what I'd like to do at this time is invite my coworker Jason Townsend up on stage and he's going to give you some really cool demos. Thank you.

Thanks, Dave. So I'd like to go over to demo machine number two and show you some of the stuff that we've added in Panther. Can we switch to demo two? All right, and I'm going to be looking at what we've done from the command line side. You heard Dave mention that we've added some new command line tools. One of those is called DSCL. And if any of you are familiar with NetInfo, you may have used Nickel before. DSCL is kind of like Nickel, except that it uses directory services. So I can just say DSCL.

Local Hosts, and I have an interactive prompt that I can use to do a wide variety of directory service operations. So at the top level I can see all the plugins that I have. For example, I can go to NetInfo for the local domain, and I can see various record types are there. Let's take a look at my users.

Another thing is we have tab completion in here, which Nickel doesn't have, so any of you who use this will appreciate that. And I'll go ahead and look at the user I'm logged in as. I can just read that record. And you'll notice where the password attribute used to be, there's just eight stars. And we have the shadow hash auth authority. So there is no readable CRIT password.

All right, so, and I can use, in addition to reading data with the SCL, I can also make changes. So, for example, I could change my authentication hint. I could say, Change that to the usual. And oh, okay, I forgot to authenticate first. So you can also authenticate as your administrator.

And then I have history as well, so I can replay those commands. And now if I reread that record, you can see that I've changed the authentication hint. So we've also got a man page for DSCL. It talks about all the things you can do. And there's a lot of stuff there. We've also added the man page for directory service.

So we should have, you know, any of the command line tools that we've got there are going to be going to have man pages you can look at on the system to figure out what you can do with them. Another feature I'd like to show you is called the DS API logging. This is something that we had in Mac OS X too, but we've made it a little bit better in Panther.

And if you haven't used it before and you're doing any work with Directory Services, either developing a plugin or writing an app that's using Directory Services, you're definitely going to want to check this out. So as root, I can do a kill all user two on Directory Service.

And that's just going to send a user to signal that will turn on the API logging. And then, for example, I could go ahead and bring up directory access. That'll cause some directory service calls to happen. And if I go look in console, I've got my system log up here.

I can see a whole bunch of calls coming through from directory access. There's actually a really cool feature in console. If you haven't seen this, this is really awesome. filter based on any string, and it will show you only the lines that match that. So I can't take credit for that, but I use that thing every day.

So you can filter to just the app, and we're showing also the app name here. If you've used this feature before, we used to show the PID, which we still show, but now you can get an idea of, well, which client is coming in talking to directory service without having to go look at top or figure those things out on your own. So that's API logging.

Another thing that we've added in Panther is called DSPerfMonitor, and what that does is it allows you to...

: So, I'm going to go ahead and do a DSCL command there. That'll just run one command and then complete, and that actually is doing a get-dir-node-info on my local domain and showing me the auth methods I have and that it's read-write and that sort of thing.

So now, if I go back, do dsperfmonitor-d, then it will dump the API statistics into var log system log, and let's see, I can go ahead and turn off my filter here, and you'll see a bunch of tab-delimited data here at the bottom that we could go ahead and bring in to Excel or whatever spreadsheet you want to put it into and take a look at it. All right, so I'd like to go back to the slides now.

Okay, so there's some other changes I want to tell you about if you're doing any plugin development or if you're using the Directory Service API. There's lazy plugin loading. We've added some new standard record and attribute types you want to take a look at. There's also support for plugins in directory access, and I'll get into that a little later. and I'll also tell you an update about our open source code.

So lazy plugin loading. This is a feature that we've added in Panther, and the main goal here is to improve the boot time and reduce the memory footprint of directory service. And the way we do this is we only load the plugins that we need. So for backward compatibility, this is an opt-in.

So there's two keys you'll want to add to your plugin's Info.plist. The first one is DSOK to load lazily. And that's going to tell us, yes, this plugin wants to opt in for lazy loading. The other one is an optional one, which is called DSNodesToRegister. And that allows you to specify a list of nodes that Directory Service will register for you without you actually even running. So I have an example of that on the next slide here. This is from the combined BSD flat file and NIS plugin. It registers /bsd/local. You can see there. So that's this array of dictionaries going on there. And the DSOK to load lazily is at the bottom.

So there's some API additions. The first one, hopefully you'll be excited about, is we have an umbrella header. So anyone who's ever programmed with Directory Service, before you had to include probably four different header files to do anything, and it was a little confusing and the names were hard to remember. So now you just include DirectoryService/DirectoryService.h and everything works if you're developing on Panther.

We've added some new standard record and attribute types. There's a few examples there. There's a lot more, but you can check out the header files on your Panther developer tools. For example, we have people, which is for contact information. This is if you want to have that contact information but not attach it to a user record. We also have a record for the auto server setup. Maybe you've seen the demos of automatic server setup on Mac OS X Server. We store those in auto server setup records. We've also added keywords and XML plist is one we use in the auto server setup.

We've added one new API call, which is DSDUDERNODEAUTH on record type. This is pretty much the same thing as a DUDERNODEAUTH, except you specify which record type. So that lets you work with records other than users. And the main thing we do this with now is the computer records when you have a PDC set up that uses this API.

So, directory access plugins. We actually had support for directory access plugins beginning in 10.2. And for those of you that aren't familiar, directory access is the tool that you use to configure Open Directory, which is an application's utilities. This allows you to provide a custom interface when someone clicks on the configure button for your open directory plugin. And we actually use this system for all of the UI that you see in directory access for LDAP v3, NIS, Active Directory. All of those have plugins in directory access.

We're going to be documenting that in an update to our developer documentation. And if you want to do this, essentially what you need to do is factor your configuration so that all of the UI is going to be in your directory access plugin and the back end of it will be in your directory services plugin. So you'll use the directory services API to actually make your configuration changes. Normally this is done by doing plugin custom calls and packing up your configuration in the DS buffer as an XML plist or something like that.

So why do we suggest that you do that? It's because directory access is a remote tool. It can actually be used, for example, to connect from a PowerBook to a headless XServe over the DS proxy. So if you go to the server menu in directory access, you can connect to whatever server machine you want and configure it. So the only way for you to get from the machine running directory access to the appropriate place to put those config files is using the API because we have a reference for you that allows you to use that remote connection.

You need to keep in mind because of this that there may be different versions on both sides of that connection, and we actually support Panther connecting to Jaguar. So we actually keep around some of our old plugins, for example, LDAPv2. Even though the directory service plugin is gone, there's still a directory access plugin for that, so you can continue to configure that. If you want to work on a directory access plugin or directory service plugin, let us know. It should be pretty easy to do the stuff in directory access. It's all using Objective-C and there's only a few methods you need to implement.

So we've done a lot for Panther. We've enhanced the LDAPv3 plugin. We've enhanced password server support with auth methods and replication support. We have a combined NIS and flat file plugin for those of you who have legacy UNIX configuration information. LDAPv2 is being retired. We have a brand new plugin for supporting Active Directory that doesn't require any schema changes. And we've made changes to local authentication. Kerberos is dead and Kerb - or Crypt is dead. And Kerberos is coming.

We've enhanced the SMB Windows Network plugin. Slash Network is now based on Directory Services. Directory Services has man pages, it has a command line tool suite, and there are some very, very minor changes if you're developing a plugin, but there's only a handful of people developing a plugin, so this doesn't affect a lot of people. Here's a roadmap of some interesting sessions. We have the security session, Kerberos, Mac OS X Server overview, server in depth, authentication, desktop technologies, and network security best practices on Friday. I'll be here all week. I'll be at that presentation.

You can contact myself or Skip Levens or Jason Townsen if you want, but our email addresses are up there. And for more information, there's a lot of documentation. We have the Directory Services API documentation posted at the site, although I've heard these - I heard we renamed all these URLs and I didn't get them updated, so go to the developer website and we're under networking, wherever they've moved that to. We have Darwin Open Directory. We have the Open Directory S/4HANA. The server documentation, surprisingly, is very good, and in particular, the Open Directory Technical Brief. Now, that's a fantastic tutorial on directories, just in general, conceptually, high-level stuff. I really recommend anyone doing directory work read that.

The Mac OS X LDAP schema. Everyone last year said, "Where do you document the LDAP schema?" Well, it's in the Open LDAP config files. We aren't keeping any secrets, but we're going to pull that out into one of the new 12 manuals for this release of 10 Server. But you can always go to the Open LDAP configuration and see what our schema is. Mac OS X security APIs are another excellent reference. And then there's the Open LDAP project, the SASL project, the PAM project, and Kerberos are also related technologies that are available to you.