Anyways, we're here to talk about Apple Open Directory and specific authentication. Based on your support last year of the overflow room at San Jose, they decided to give me two sessions this year. So you can be bored this afternoon, and I look forward to seeing all of you tomorrow, tomorrow morning's Open Directory session. As the announcer said, I'm David O'Rourke. I'm the engineering manager for Open Directory, and today we're going to talk about authentication.

What I'd like to do is review the current Jaguar feature set, because I know everyone here, some of the people might be new. We're going to cover new features for authentication. They break down into three basic areas. We have local authentication, open directory password server and what we're doing in that space, and Apple single sign-on slash Kerberoes implementation. We'll do a summary, we'll do a wrap-up, and hopefully we'll have some time for Q&A if I don't go too long.

So, Jaguar authentication, the product that most of you probably had installed on your PowerBooks before we gave you the developer CD. Jaguar currently supports Crypt. All of us are familiar with Crypt. It supports the Open Directory Password Server. It currently supports Kerbero, it supports LDAP bind, and it supports any other method of authentication if you implement an Open Directory plug-in.

In Jaguar, we introduced the new notion of a user attribute called the authentication authority, which is a hint to Jaguar as to how to best authenticate this user. You're going to see later in this presentation and throughout the Panther process that we're going to start leveraging the authentication authority much more into the future.

So what authentication authority values do we have right now? We have basic, and this is an attribute stored in a user record, and if its value is basic, it basically says the user is using crypt. If this attribute is absent, we also assume the user is using crypt, because any existing user record that was crypt-based didn't have an authentication authority. So really the basic authentication authority is there for intellectual completeness. It doesn't serve any purpose other than to clearly indicate this user is crypt-based.

The new attribute that we introduced in Jaguar was the Apple Password Server attribute. This consisted of a keyword, Apple Password Server, which is up on the screen. It's followed by an ID, a public key of the Password Server, and the network address of the Password Server that you would contact to authenticate. This is how, in LDAP or NetInfo, we indicate that a user's authentication request should be redirected to talk to the Apple Password Server.

So for Jaguar changes, we had a lot of infrastructure work to do. We had to get login window onto directory services. We had to get secure framework onto directory services. We had to pamify the entire Core OS. Most of the FreeBSD code we adopted wasn't adopting an API abstraction. And because of that, we couldn't replace the crypt password, and if we did, these apps would break.

And we had the directory service APIs, of course, that already supported this. So the major accomplishment for Jaguar last year was that we managed to get most of Apple software to not care how passwords are handled. In Puma or 10.1, that was not the case. If you remove the crypt password, there was a lot of software that broke. So the major accomplishment for Jaguar was we got all of Apple software cleaned up not to care.

The Open Directory Password Server was also introduced with Jaguar, with Jaguar Server. It's a password server. It's based on the open standard of Sassl, and it provides comprehensive network authentication support for a wide variety of network protocols. How many people have heard of APOP? How many people have heard of CRAM MD5? NT Land Manager, SHA-1, shall I keep going? The Password Server supports all of these methods so that you can have a single password supported across multiple network authentication protocols. For those of you who have implemented authentication systems, this is no easy trick.

So the authentication methods that we support with Password Server are MD5 Digest, CRAM MD5, NTN Land Manager, APOP, WebDAV Digest, Two-Way Random, and Apple's own Diffie-Hellman Exchange, which is used by AFP. I've associated the most common protocols that use each of these auth methods, but any protocol could, in theory, use any auth method, but, you know, and typically these are what they're associated with. All of these methods are secure to some degree if you believe network challenge response protocols are secure, so none of these disclose the clear text password on the wire. But all of them are necessary to support various network service protocols.

So, last year I had a slide which I heard after the feedback was quite popular. It just runs you a quick diagram through how a Password Server authentication works for logging on to a mythical network service, and I'd like to drop in a network. So, we have the Mac OS X client. It will be talking to the Jaguar server, AFP, FTP, IMAP, SMB. It's going to look the user record up in a directory server, and it's going to verify that with a Password Server.

So, the first thing that happens is a Mac OS X client contacts the Jaguar server and says, hey, I want AFP service. I'd like to do two-way random number exchange, and my name is George. The Jaguar server takes George, looks them up in the directory server, and what it retrieves from the directory server is George's name, George's UID, and the very most important attribute is it retrieves the auth authority.

The auth authority indicates that George is Password Server based, and this is the network address that this user should go to. So, that's the first thing that happens. So, the Jaguar server contacts the Password Server and conducts a network-based authentication, choosing an appropriate authentication method. The Password Server responds with success, even if the password's wrong. No, I'm just kidding.

And the Jaguar server says you can log on or says no. So this is very similar to Kerbero authentication for those of you, but it's password server-based and there's no credential management going on here. But the password server is the repository of the user's passwords. There are several advantages to the password server. It maintains a single password for all network protocols.

Part of Apple's strategy, if you haven't heard this, is we take open source software and make it easy to deploy. Well, a lot of network administrators don't want to set up separate password databases for all their different networking protocols. They want to create a user once, they want to assign a password once, and they want to know that that user can log on to every single network protocol they might turn on today or tomorrow. So the password server's role is to maintain a single password for all passwords.

possible networking protocols that we support. That means we need to allow support for secure legacy network authentication protocols. If you don't have this requirement, you don't have to have a password server. If you do have this requirement, you have to have a password server. Most people have this requirement. It also supports long passwords up to 511 bytes.

I picked bytes and not characters because UTF-8 isn't necessarily a single byte per character. For arbitrary strings, it may be as little as 200 characters, the user types, but it is 512 bytes. It enforces password policies for all accounts. It's not subject to hacking by download of hashes.

How many people are familiar with offline dictionary attacks in the audience? You can't do that with the password server. Not even the password server administrator can capture the hashes out of the password server database. There's no known attack that I know of on the password server that can get the hashes into a user's hand where they can work them offline.

It supports standard security techniques such as slowing down on successive failures, policy to shut down the account after three or four failed attempts, all of those standard things. And more importantly, it also has its own RSA public key, private key pair so that the password server can't be spoofed.

In the design, if you could set up the password server and take over an IP address and just have a password server that said yes every single time, the client would trust what the password server would say and allow that user to log on. Well, the client, when it's contacted, when it's contacting the password server, actually challenges the password server to prove it knows the private key. So you cannot spoof being a password server on the network and we're going to leverage this more for some of the new features in Jaguar.

Jaguar Kerbero support. Thanks to our MIT brethren, Jaguar came with full Kerbero support. MIT provided us with a very robust Mac OS X Kerberos client. And Apple provided configuration documentation, a lot more than what's listed here, but that's one example document that Apple provided of how to configure Kerberos in Jaguar.

Apple Kerberized many servers and clients in the Jaguar time frame. There's the list. For Jaguar client, we Kerberized AFP, we Kerberized the Mac OS X Mail application, we Kerberized login window, and we Kerberized Telnet. In Jaguar Server, we Kerberized AFP, we Kerberized IMAP, SMTP, I think we Kerberized POP. Did we Kerberize POP, Marshall? I don't know. Okay. And we Kerberized the FTP server that we shipped with Jaguar Server.

So with Jaguar, we did a lot of things. We expanded the set of choices for authentication. We abstracted the entire operating system to not care how passwords are managed. And Panther is going to introduce even more change now that we have these building blocks. So what I'd like to get into is what you're all here for, which is to talk about what we're doing in authentication for Panther.

And first, we're going to talk about what changes we've made to local authentication. And what I mean by local authentication are the user records that are kept locally on your PowerBook that are created by the setup assistant or by the local system pref thing, not user records created by the server tools. The first thing that most of you should stand up and applaud is Crypt is dead. There is no readable Crypt password.

The default local authentication is now stored in a shadow file for all local user accounts. That's strange bulleting there. I had that file without a bullet. File for all local user accounts is not its own bullet point. Anyways, Crypt still works, but no administration tools on Panther will create a Crypt user. No administration tools will create a Crypt user. It is not broken. It's continued to be supported. If there are legacy Crypt users, they will work just as well as they've always worked.

But no GUI tools that we ship with Panther will create the users with Crypt. Your application should not be relying on Crypt passwords. Panther will break applications that require a readable Crypt password. This is not a bug. It is a necessary evolution of the OS for us to close this security hole. If your application requires a readable Crypt password to authenticate a user, you must adopt a password verification abstraction.

There are three abstractions that you could adopt to get off of readable CRP passwords. You could use PAM, which is a pluggable authentication module from Linux. We support it on Mac OS X. If you adopt PAM, your application will not care how passwords are authenticated. You can call the security framework.

It does a number of services for you. I attended an excellent overview by the security team of the authorization framework. You could adopt the security framework to do your password verification, or you could work with us and adopt the directory service APIs to do all of your password verification.

If your application is not using one of these APIs, it will break and has already been broken when running on Panther. In the CD that we've distributed to you with Panther, the default local user created by the setup assistant does not have a CRP password. If you can't authenticate in your application with that user record, it's not a bug in the OS. It's a design decision and a security hole that we finally patched.

Just in case this isn't clear, your application is not using one of these APIs. It will break when running on Panther. By the way, your application's already broken on Jaguar with a password server-based user, but most people don't know that, and most people haven't tested with network users. So this is not something new. We're just tightening the noose a little bit in order to keep you guys employed.

So what have we done for the authentication authority matrix? Well, we had BASIC. That's Crypt. We still support that. If you create a user, you set the auth authority to BASIC, you'll get a Crypt password. We don't recommend it. It's not secure. We have the Apple Password Server. No changes there. We still support the Password Server.

But we've added a new attribute that we call ShadowHash. A user record with an authentication authority of ShadowHash indicates that a user record has a password hash stored in slash var slash db slash shadow. That file is root-readable only, not even admin-readable. It's root-readable only. To read the hashes out of that database, you have to have root privileges on the local machine, and on Panther, root is not enabled by default. So this is as secure as any system we know about that stores the passwords locally on a hard drive.

Panther stores all of its passwords for local users in VARDB Shadow. It's a secure file system directory. We use a SHA-1 hash to store the password. We have support for more than eight characters. So those of you who want eight-character support and want it to be significant to more than eight-character support, we now support that. The system is no longer subject to hash download attacks. So students cannot walk up to your lab machines, run in IDump, and walk off with the password database.

Crypt is still supported, as I've said, but no administration tools in Panther will create a crypt-based user. And all of the Panther command line tools that we've been able to identify have been updated to use the directory service APIs to change passwords. So you can now use changepw, changepassword. All the tools we found now use the DS API, so you can change your passwords through command line or through the GUI. So that's local authentication.

So authentication in Panther continues because we haven't been idle on what to do with network authentication as well. So there are new features for the Password Server. We have new authentication methods in the Panther Password Server. We now support secure multi-master replication for the Password Server. You can distribute copies of the Password Server around your network. And we've upgraded the client so the client knows about the replicas and will fail over to use a replica when one of the replicas is talking to you goes away. We now have global and per-user policies.

You used to only be able to set password policies per user record, which meant if you wanted to start a global change, you had to visit each user record. Well, that was silly. So we fixed it to have global policies. And we're integrating support for Apple's Kerbero Server, which is really MIT's Kerbero Server, and I'm going to come back to that later in the presentation. It's better performance. There's far less networking traffic and an extremely embarrassing faux pas. It takes 14 packets to authenticate a user on the Password Server. How many of you think that's just idiotic? It is. Okay. We fixed it. It now takes two packets.

By the way, if anyone can figure out how to do authentication in a single packet, I want to talk to you after the session. Better performance, less networking traffic, and we have many new command line tools to automate policy management. There's now a PW Policy tool, which lets you set all the policies from the command line. It's in user/smin on the server. Give it a try. It has a man page.

The new authentication methods is we've added support for VPN authentication. VPN, a typical authentication method required is MSCHAP2. The Password Server now offers MSCHAP2 support. And if you attended the server detail overview, many of you are familiar now, we have a PDC. We had to add several authentication methods to support hosting a PDC. So we added a number of auth methods so that we could host Windows primary domain controllers.

So Password Server authentication methods look like this. We have MD5 Digest. That's supported on both platforms. We have CRAM MD5. We have NT and Land Manager. We have APOP. We have WebDAV Digest. We have MSCHAP2, which is new and only supported on Panther. And we are retiring to a random. Every AFP client, it's supported in Jaguar. We're removing it in Panther because everybody since 8.1 uses Diffie-Hellman. The DHX exchange.

So two-way random wasn't being used that much when we profiled all of our user data and there's some issues with it. So we're retiring to a random in 10 server. There are other enhancements to the Password Server. So new password policies. I went over this. Global and per-user password policies.

We now allow the policy to be set in one place so you can change your passwords from minimum 8 characters to minimum 12 characters by making one single change. Or you can override for certain users. There's that user who's calling you a lot on the phone line and you don't like it. You can set the password policy for them to be like 18 characters as a minimum password.

Although I think that might cause more phone calls. I'm not quite sure whether that's a good thing. We have many new password policy features. We have history, we have character set requirements, and there's a new tool for password policy management, PW Policy. It's easier to show the new features than inventory them, so I'm just going to throw up this screenshot and let you all get a good look at it. So we can disable an account on a certain date.

We can disable an account after a certain number of days. We can disable an account after a certain number of days of inactivity. And inactivity in this realm is defined as successful activity. So failed attempts don't keep this alive. They have to have logged on successfully at least once within that period of time. And we have the, of course, after a certain number of failed attempts.

Passwords must be a certain number of characters that contain at least a letter, contain at least one numeric, differ from the account name, differ from the last X passwords used, and be changed every X minutes, days, months, or years. Per-user policies are a subset. Now, you can override the global policies on a per-user basis, so I could go into a particular user, say I've hired a contractor to come onto my site and I want to disable it. When the contractor goes away, I can set a disabled logon. You can see all of this in Workgroup Manager. Those are some of the things that we can do. And that's one of the policies we're supporting now in Panther.

Secure replication. Schlepping passwords around the network in the clear is not a good idea. So when we designed replication from day one, we have leveraged the public key/private key pair that the password server has. Note, we use the SSH key gen. We don't share the SSH key, but we use the exact same key gen tool that SSH uses to generate our keys.

So we are basing our replication on encryption done by using SSH. We're using the public key/private key pair that is already present on every password server that's already been deployed on Jaguar. Replication can occur on change or it can occur periodically, like every 20 minutes, every half hour. All replicas can accept change password.

That means if you're cut off from the mothership for a period of time, your users can still reset their passwords. And when the replication occurs, we merge the data and we do all the right things in knowing who has the later record, all of that sort of stuff that you would expect from a professional server organization.

All replicas can accept change password. All replication sessions are encrypted end to end with 128-bit key using RC5 encryption that we get from the security framework. There is no clear text data passed at any time during password server replication. I'd like to repeat that. We never pass the clear text on the wire.

Client replica discovery is quite exhaustive. If you have a replicated system but your clients are still beating on the same IP address, it doesn't do you any good. So we came up with a multi-layered approach for the client to discover a replica. The replica picking is transparent to anyone using the directory service APIs or any of the higher-level APIs. You don't have to know that a failover is occurring.

Replica discovery is done in parallel. If you have 20 servers deployed and 19 of them are down and you have a two-minute network timeout, I doubt your user wants to wait 38 minutes to find the 20th replica. So we discover the replicas in parallel. The first thing we have is we have a local cache file on the local machine that knows the IP address list of all the replicas for the password servers. If we find the password server there, we'll start working with that IP list first.

Obviously, in the general sense, we don't have to worry about that. In the Genesis case, we don't yet have that replica cache, so we move on to a configuration record in the directory server. So there is a config record in the LDAP directory server that is for the password server, and it lists all the IP addresses of the password server. The client downloads that configuration record and populates the cache file with that list.

We also use Rendezvous, which I'm going to come back to because we have public key private key. We can actually use Rendezvous and it's still secure. And as a last-ditch attempt, we assume you might be trying to log on to a server for which you can use Rendezvous. You've changed its IP address, and so we'll loop back to the local machine to see if a password server is running locally and authenticate there. And as a last resort, we'll actually use the network address listed in the authentication authority.

If Replica is available, I think we'll find it. I want to go back to the Rendezvous case real quick. The Password Server registers Rendezvous using its public key. We know the Password Server's public key, so we can actually ask Rendezvous, is there any Password Server on the network with this public key? Now, we don't trust that that Password Server's actually who it says.

We still engage in the challenge to have that client prove to us it knows the private key. But we were able to leverage Rendezvous to use a service discovery protocol so that you can change the IP address of your Password Server, and your clients will find them using Rendezvous.

We thought that's pretty slick. Thought I might point it out to you where you have some security fallback. It's kind of nice to combine Rendezvous, which is local network broadcast authentication, or discovery with a secure authentication challenge. It could be used for SSH as well. I haven't thought about it much.

So integrated Kerbero support. How many of you haven't heard that Apple's moving in a big way toward Kerbero? OK. So we are integrating. Luke. OK. Apple will ship an enhanced MIT KDC. I'm not sure the MIT team would think it's enhanced. But no, we're going to enhance it. The enhancements will allow the Password Server and the KDC to share and synchronize their password and policy information. Apple's KDC will leverage Password Server replication, so all the KDC data will be funneled through Password Server replication sessions.

And from a customer's point of view, the Password Server and the KDC are a single system, so they won't know that they've deployed a KDC. They hopefully won't care because--and if they do care, we can say we're using Kerbero, and then that should shut them up. So legacy authentication support is still provided by the Password Server.

So what we have, in our opinion, is the best of both worlds. We're moving toward Kerbero, but we aren't holding your legacy non-Kerbero clients hostage. They can still engage in legacy authentication. So this brings us to Apple's single sign-on strategy, which is the last section of my presentation.

Single sign-on. This is defined as, by my management, as a user typing a password into logon window and not having to worry about it ever again. Apple is adopting Kerbero as our network single sign-on approach. Apple is basing all of our Kerbero work on the MIT Kerbero implementation. Panther can be configured to work with existing Kerbero deployments. Apple is not changing Kerbero.

We're tweaking the KDC, but we're not changing Kerberoos. All we're really doing-- and I didn't realize this until we were almost done-- is we're providing configuration tools to make it easier to adopt. Kerbero's is excellent, but in Apple's opinion, has suffered some barriers to adoption. And I'd like to go over some of those barriers so that hopefully you guys will share with me what you think we're actually adding, where we're adding value.

So the first barrier to adoption is you needed a KDC. You're required to deploy a KDC, and up until now, that's been quite an effort. And up until Panther, there was no KDC that ran on Mac OS X. I think Heimdall ran, but there was no MIT KDC that ran on Panther or Jaguar.

Directory services integration. This is actually fun. Marshall's going to laugh at this, but when we met four years ago at WWDC in San Jose, what we realized is there were lots of Kerbero's deployments in the world, but none of them had standardized how do you integrate with a directory.

Every site had done something slightly different. So that's a barrier to adoption. How do you integrate with a directory system? Lack of integrated user account management. I mean, there's lots of scripts and stuff, but there's no GUI tool where I can say create a user, and it also creates the Kerbero's principle and does all the things you need to do.

You had to register all your hosts and services, so if I wanted to turn on an AFP server, I had to remember to create a host principal in my Kerbero server. I just couldn't turn the AFP server on, or mail, or some such. Command line level configuration of the Kerbero's clients. I mean, I can handle that, but I don't think most of our customers can.

And there was no support for legacy network authentication. If you deployed Kerbero, there was no way for me to do an NT and LAN manager authentication for the Windows 95 client that's never going to be Kerberized. So how do I get it onto my SMB servers if it's been Kerberized? So we saw these as barriers to Kerbero's adoption, and the first thing we did was set out to address each one of them.

So for Panther Server, Requiring a KDC? Well, we got that covered. Panther's shipping with a full KDC setup by default. If you complete the setup assistant on a Panther server and have turned on a directory server, you have deployed a KDC. End of discussion. No arguments, no ifs, no ands, no buts.

Directory server integration. All the directory server tools in Panther know about the KDC and use the KDC. Lack of integrated user account management. Worker manager, when you create a new user, will create a Kerbero's principle for that user, as well as a password server entry. Registration of all host and service principles.

If you complete the Panther Setup Assistant, how many of you saw the cool Auto Setup Assistant demo? If you turn on all the services that you can turn on from Panther, if you complete the setup assistant and there's a Kerbero server on the network, we will have already preregistered all the host principles for you for those services, even if you haven't turned them on.

Command line level configuration. Panther Desktop will optionally auto-configure itself out of Kerbero. There will be no command line configuration in Panther of Kerbero. There can be if you prefer that, but there will be an option to have auto-configuration. No support for legacy network authentication. Well, we got that covered with the Password Server.

Its whole reason for being is legacy network authentication. We've integrated it with the KDC, so you can have the best of both worlds. You can support 95% of your network as Kerberized, and one or two machines that need to come in through a legacy protocol still can and still have the same password.

So Kerbero will be fully supported in Panther. The Apple single sign-on changes don't modify Kerbero. All we've done is provide some automated tools to assist the user with configuration. Panther Server will be auto-configured to use Kerbero if Panther Directory services are deployed. But what about integrating with non-Apple Kerbero systems? Well, how many people have deployed Kerbero at their site? You guys already know how to do this, so the way you'll do it for Panther is the same way you've always done it for Panther. You're already comfortable with the KDC. You know how to create host principles.

There will be no difference in deploying Panther into an existing Kerbero deployment. If you deploy our KDC, you get the auto-setup features. If you don't deploy our KDC, you set it up the way you've always set up services to use a KDC. The administrator is therefore responsible for the Kerbero's configuration.

So I get this question a lot. How does Panther actually auto-configure Kerberos? Well, we're using the authentication authority. We now have defined an authentication authority in the user record with the keyword of, guess what, Kerberos. If we see an authentication authority with Kerberos, logon window will rummage around in the directory looking for Kerberos config information and auto-configure the Kerberos client. If your directory contains that information, your Panther client will auto-configure to use Kerberos.

If your directory does not contain that information, it will do nothing. Most directories don't contain this auto-config information because we haven't told you what it is yet. So rest assured that Panther will not be automatically configuring Kerberos out of your directory system because we haven't even figured out ourselves yet what the final format of the data is, but we will.

Sites can add the auto-configuration data to legacy deployments if they want. We'll set it up for you automatically. So we're leveraging the existence of the authentication authority in the user record, and that will trigger Panther to look for config information to configure the client to use Kerbero. So customers can choose. Customers can choose to deploy Apple services, and Kerbero will be easier than ever.

Many of the barriers to Kerbero adoption have been addressed in Panther, or customers can configure Panther to work with existing Kerbero deployments, no different than how they do other platforms. So it's really up to you as a network administrator as to which system you deploy. But either way, Panther will support Kerbero.

Authentication long-term. Apple is investing heavily in Kerberoos. Where Apple can be an 800-pound gorilla, we can actually make a lot of changes. Let me repeat the first statement. We are investing heavily in Kerberoos. You should probably be doing the same. We are aggressively migrating all of our networking products to be Kerberoos-based if it's appropriate.

We're going to ship a KDC. We already ship a client. And session 108 is a must-attend for any network services developer so you can learn how to use the Kerberoos APIs. All Kerberoes, all the time, is in Apple's future and yours. Plan today for the changes you know are coming.

I'd like to wrap it up at this point. So, Jaguar introduced new authentication support. Panther has changes in three important areas. We've changed local authentication to not be crypt-based. We've enhanced the open directory password server to be fully replicated. There's new auth methods, new policies, new tools. And Apple is aggressively working on making it trivial for server administrators to deploy Kerbero on their network.

An interesting history through the years is we started out with Mac OS XO and it supported Crypt. XO we added Crypt, LDAP Bind, and the DS APIs. For Mac OS XO we support Crypt, LDAP, Kerbero, DS API, Password Server, PAM, and Security Framework. And for Panther, we've dropped Crypt. We still have all the other support, but we've added replication.

And moving out into the future, Kerberoos is more and more the story. And we're going to be working with MIT to define how that evolves and what we do. There's some roadmap. The security and architectural overview, you should really go back in time and listen to that yesterday.

108 is on Thursday at 9:00 a.m. That's Kerbero for Mac OS X. The Mac OS X Server overview is also an excellent thing for time travel. That was at 2:00 p.m. Mac OS X Server in depth preceded this, so three of the sessions have already happened. Directory services is tomorrow. I will be emphasizing authentication far less in tomorrow's talk. We'll be talking more about the enhancements to LDAP and other things. Managed desktop technologies is heavily based on directory services. I recommend if you're interested in directory services and authentication, that's an excellent session. And network security best practices is on Friday at 10.30.

If you have any questions, you can contact me or Skip Levens. And for more information, here's a list of documentation and open source references. We have the Directory Service API documentation. Directory Services is open source as part of Darwin. We have the Open Directory SDK. We have Mac OS X Server documentation. I particularly recommend the one in the technical briefs called Open Directory.

That's an excellent tutorial on the overview of what a directory system is. We have Mac OS X LDAP schema, which is stored in the Open LDAP configuration files, and we have the Mac OS X security APIs. There's also some third-party sites. OpenLDAP is an excellent LDAP server. Sassl is done by Carnegie Mellon. We base our Password Server on the Sassl protocol. PAM is PAM, and it's a Linux password abstraction. And there's Kerbero, of course, at web.mit.edu/kerbero.

Oh, somebody added this slide. I haven't seen it. So who to contact about Kerbero would be Andreas Windecker. Is that correct? Bob Frazier, Catherine Wink, and enterprise-level web object support and consulting. I'm not quite sure that's appropriate for this session, but maybe it is. We have some more reference libraries. It appears somebody cut and pasted some slides into my presentation.