Managing and Deploying Open Directory. I'm Joel. (Applause)

I believe that Nicole teed up this session a little bit more than it should have been. Lots of people have been asking me about something -- but they don't know what yet. So we'll get into that in a few slides. So some new ways of deploying, new ways of doing things with Leopard, and then like I said we have a case study of using Open Directory in the Tiger realm with a variety of (inaudible) clients.

So what's new in OD 4? Everything is tiered. This exciting and this is cool. Tiered Admins, tiered replication, tiered lots of stuff. Net Info is dead, and we'll talk about RADIUS a little bit. And I don't have a parrot like Nicole did. I know. I think I got a better slide though, I got a better slide.

So to reiterate a little bit between the architectural differences between 10 and 10.4 , and kind of why you care -- this was 10.0, lots of different layers. OS X software there in the red. That would work with directory services there in green, which would then contact the various different plug-ins and pieces that would go through there.

What was actually going on was two different forms of entry to lib sys API, which is the lib C things. And the directory services APIs, which is if you're writing specifically to OS X. So if you just had a UNIX application that you were looking at porting over you were usually using things like get P W Nam, and things like that. And that goes all through the lib sys side. Those would actually hit three different daemons.

Lookup D directory services and member D. Member D was added in 10.4 to do group resolution. Lookup D has always been there doing Net Info and other things. And then directory services came around 10.3 to give you all the good DS fun stuff. Like Active Directory and LDAP.

So we had three different systems that were constantly talking to each other. That's an awful lot of IPC look ups, interprocess communications between those two. And you were taking a hit to performance and latency on having to have that happen. All right. We understand all that. We know that. It made directory services a lot more complicated than it should ever have been. More complicated to trouble shoot, more complicated to work with as an Admin, more complicated for programmers to actually program to.

So time for a clean up. We've taken all of that and the Leopard architecture is now much more monolithic. That actual green layer is really, truly just one service. Which is the directory service daemon there. So single directory services, caching, group members, local data store access, and most importantly, DNS host resolution.

In 10.4 if you actually did a DNS look up, even though you're kind of doing it through directory services, lookup D was still handling all of that. This meant that sometimes when you were browsing the Web and things like that you had higher latency for DNS look ups than you otherwise really wanted to, because it was having to be passed from one system to another. So by putting this all into one layer of directory services, we have much better IPC dispatch, much better performance, and overall we think you should see a much more snappier, to use a technical term -- system.

So even if you don't realize the directory services changed in this way, and even if you're not using a directory service period, you should find a faster user environment just based upon these changes. All right? Lookup D and member D will not be running in Leopard, so you shouldn't even be using them. So, what replaces Net Info? We have a local data store replacement. Right? Net Info, very long time. Historical usage. Great stuff. How many people are currently using Net Info across the network right now? Ooh. Two of you. All right. Well, how many people are using NIS.

So there's five. So we have more people using a ten-year-old deprecated solution than Net Info. So if I got to cut one, I'm more than happy to cut Net Info than NIS. Sorry about that. But you knew it was coming. Yeah.

So Net Info did a lot of things, but we've really not supported, really, Net Info service since 10 2.

Could hold about 10,000 entries. Decent for a small to medium business. But certainly has scaleable issues. String data, no binaries, right access controls, but there were no read backs as controls. So you're very limited with a lot of the configuration that you could do. So no longer. We're moving on. All right.

There's a lot of RPC -- remote processes -- remote processing communication -- if you wanted to firewall off your Net Info solution. It's like firewalling NFS. It's a random collection of ports it was going to use. So you couldn't really do anything. So it really hurts when you're trying to make a more secure solution.

There we go. And so data going into there, all going into the Net Info database. Net Info retired -- this is my parrot slide.

Yeah. Jersey's going to go up on the wall on One Infinite Loop. You're going to see it over there. You know, in five years from now you know, the younger generation of system Admins are going to walk by and Daddy, what's Net Info. And you can wax poetic and talk to them about the grand old time you had with the NI Util and Nickel, and all those things that nobody will know any more.

So a little bit about the local data store replacement, and we'll actually do some poking around with it. Net Info being retired, we're banging you over the head with that, but we really want you to understand that. So records are P-lists. For the local -- for the local records imagine if you will that you took the contents of Net Info and you essentially catted it out with NI Util or Nickel, or any of your other favorite N utilities, and you put that into just an XML delimited P-list.

That is what you're going to find. There's a folder directory structure that matches the directory structure that was given to you virtually through Net Info. And every record in that directory structure is going to be a plain text P-list file. All right? So very easy to get into, very easy to change. We'll talk about that in a little bit. So one less daemon running. It's just all one piece there.

All Net Info data is going to be migrating during your install. You shouldn't have to worry about this. All right? So when you install, when you upgrade to 10.4 all of that is going to be taken care of for you We're really not going to support network not info. All right? We're really not going to support it. LDAP directory and NIS are on the way forward.

All right. So all three of those are very much supported in Leopard. We've actually given NIS quite a bit of love . So we should see better NIS support for that. Net Info manager is gone. There's really not much point to it. All the NI Tools are now DS tools. So swap NI with DS, and you should still be able to do your jobs. This is why if you've been listening to some of the mailing lists and stuff like that you've been telling anybody that wrote a script that does anything with NI Util to use DSCL.

D S C L. The Directory Services Command Line. Which is more than happy to work with the new Net Info replacement. And if you coded using any of the lib C APIs using the directory services APIs, it is irrelevant to you whether Net Info exists or does not at this point. All right?

So we're very, very confident that about 99 percent plus of the software out there will have no knowledge whatsoever of the underlying change to this. So now we just have data going straight down into one place. There's not a whole lot of individual things in between. So now to Demo B here, and we can poke around a little bit.

Ah. Demo B. Green. Joke. That's right. Okay. Emergency joke time. Uhh -- I was hoping that I would at least make sure that you were -- this is the other one, though. This is Paul's. Which isn't running 10.5. And this is B. Which -- maybe I just need to detect displays.

Hey! No emergency joke! Emergency presenter needed, not emergency joke. So you'll have to wait on that. All right. So what of the command line here. We've made it really, really big so everyone can see. Where does it live? Well, we can go to Var, DB, there's a bunch of stuff in here that you will notice that one of them is DS local.

So Var DB DS local. We take a look inside here. Inside here is nodes. I can change into the nodes directory. There's default. Go into there. Here's my basic folder structure. Aliases, configure groups, networks, users. If I cd into users, I will actually get a list of all the users who are current on this system.

All right? I can do more on the Apple user and you will actually see essentially what you would have gotten out of Net Info. But now in a P-list delineated format. All right? More on this in a little bit. Let's get out of there. Go to System Preferences, Accounts. I can go in here, I can hit plus. And by creating account -- first of all notice that you can create groups from here, if you haven't seen that. Task, group.

You can see that there's a hay men's joke file, and this is our brand new user. All right? Now, do not do --

I will tell you something that will help you and what I really like about the fact that we are going to flat files is that as the System Administrator, there are times when you need to push out a new user. All right? And David O'Rourke told me not to tell you to tell you this.

So if he's around, tell him I didn't tell you. But what I'm interested in is not actually editing user records live. But if you're an administrator and you need a new user on these machines, all it is, is a file push. You don't have to have an interactive script on the other end.

Push out a new file, push out a password hash, and a Var D shadow hash. You now have a user record and a password hash to go with it. And all you've got to do is hump directory services, and you'll be able to use that user. Now, Dave seems to think that's a live editing of the data store, which it kind of is. But I think you will find that should work okay. But Dave told me to tell you not to say that. And back to the slides please.

So, local records. Single user mode. This is really where this becomes important, and this is fully supported. All right? In 10.4 if you went into single user mode, there were typically some services that you had to start up if you wanted to easily manipulate user records and passwords. You now don't have to do that.

All right? It's just a flat file copy. And in single user mode when directory services is not running it is perfectly acceptable to use V I on those records and make changes. It's also perfectly acceptable to boot it in a FireWire disc mode, and actually make changes in that way from the system and then reboot it live. I'm really, really excited about this, because it means when you're creating an image, you can actually put users and groups into that image just by copying down flat files to it. Furthermore, how many rabe mine users do we have out here?

How much of a pain in the behind to rabe mine the Net Info database? It was awful. Because the Net Info database, even though it contained the same data, the structure that it had was different from machine to machine. So you usually had to exclude it from all of your rabe mine transcripts.

You don't have to do that now. So -- and as I said, it's easy now to push out files with replication utilities like A R D and things like that, that can actually now begin to give you new users and such on your machines that are out there.

All right. Augmented records. Also something new to 10.5. Augmented records are kind of like the magic triangle. And since they're kind of like the magic triangle we had to come up with a name that's kind of like the magic triangle name. This is what Nicole told you to come to this session for.

So for, this name has been -- so-so in front of test audiences. So we're rolling it out. I wanted to get a graphic for it. But this is Friday. All the graphic shapes have been used up. So what we're looking for here is a geometric shape and an exciting word. And so we are know coining, you heard it here first -- the Cylinder of Destiny.

That's the reaction I wanted, you might actually hear what the waiter said. So the Cylinder of Destiny goes a little like this. You allow Admins to add attributes from -- to augment other records. All right? And we've got a graphic here that kind of shows you this. So I've got my iMac.

All right? I've used the active directory plug-in just like -- Eric and Dave intended it. All right? You're going direct app to direct -- you're using records and password resolution out of there. However, in the magic triangle scenario you are unable to do things to the actual user records themselves.

With the magic triangle you can put groups on the Open Directory side and you can actually add users from AD to those and manage those groups. But you couldn't manage those individual users. With the Cylinder of Destiny you can now create records on the other side that allow you to do this. That get augmented.

When the iMac starts up and does a user resolution, it will pull the user record out of active directory. It will then look in Open Directory for other attributes that are associated with that user. You can't overwrite attributes that active directory gives you All right? But you can add attributes that weren't there before.

Nicole showed you some ways of doing this through the graphical utilities. You have to come up with the server in the standard mode, not in the advanced. And then you can drag users in and it will allow you to set this up. I will give you information later on once we're closer to Leopard shipping. Actually, once Leopard probably has shipped.

But how to do this manually. Where you can just put the records in the appropriate places and do what you need to do with that. It's not rocket science, it's not secret sauce -- it's just a matter of making sure that information shows up in the correct places.

With this, you should be more than able to augment things like NIS. You can put augmented records into the local directory. You can put augmented records into other LDAP directories. This is not necessarily an A DOD thing. This is a directory service, directory service thing that we're giving you here. Airport base station support. This is one of the other new features, which is the RADIUS support. All right? Integrated via Server Admin. You're essentially configuring free RADIUS on OS X server. That's what we're giving you. All right?

It's specifically set up for use for WPA2 and such with airport extreme base stations, but it's a full blown RADIUS server. In no way is it free RADIUS dumbed down, so there should be lots of opportunities to do lots more with this than just supporting a bunch of base stations. We also intend on putting all of our modifications back into Darwin. So that you're able to use this if you want to compile the latest version of free RADIUS, and get that nice hotness with you. All right. Changes to OpenLDAP.

Access control lists. Who mistakenly went down the work group manager way of creating limited users in 10 3 and 10.4 thinking that they were in fact limited, because that's what the interface told you. And they were, in fact, limited. If you used Workgroup Manager. However, if you saw through any of the LDAP tools, it was just a fallacy. Now we're actually pulling that directly into OpenLDAP and actually giving you access controls on OpenLDAP so some cool things like non Admins can add machines.

All right? This was always a problem that you had to put a user out there with Admin user name and password to create machines. Especially if you're doing this through a script that's start up. You can now easily do that. And these things are all set in these flap D underscore Mac OS X server dot com file.

Now a few builds ago, it looked like this. I think that's changed a little bit. If we change some of the syntax around. But these are the kinds of things that you're going to find in that file that allows you to do some of this tiered Admin support. When you go into the GUI and you set up tiered Admins, this will generate records like this in the slash D underscore Mac OS X server dot com file that will allow you to have the tiered Admin support that really is tiered Admin support.

If you read my site, you saw we had an article up there maybe about two or three years ago that talked about using DACLs -- directory access control lists. So these are now essentially the same thing. But now actually accessed through the GUI tool. So very, very cool.

And this is a little example of it. Here we have a half Admin. Eric, the half Admin. And -- somebody got that. That's good. Administration capabilities are limited. I can then drag groups into this window. And actually set up what they can or can't do all through Server Admin.

This will do two things. One, it will create those access control list records in the slash D com file. It will also generate records in the password server that allows you to do this as well. All right? Relax privileges on groups to better serve blogging, and the wiki stuff that we have.

So now non Admins with create groups to generate wiki and kind of share points, services, around that to allow you to do that team work group. I used a lot of words there. Just to say wiki. So, and again, this is a similar article that you might find in that slash D dot com file.

Overlays. This is when it really gets cool. With Leopard, we pick up the latest version of OpenLDAP, which is 2.3. Currently we're running on 2.2 in Tiger. So 2 3 provides some very fun stuff. Overlays it one of them. And an overlay is a little bit of a code that runs on the LDAP server, and it will actually be able to respond to requests before OpenLDAP goes digging in its database for it.

These are all, again, set in the LDAP configuration files, and here's an example of them. So we're providing an overlay for nested group support. If you're a Legacy UNIX application, you don't know how to use nested groups are an LDAP. Because you're not going to go chase them all down. So now you can put an overlay in there that's actually going to do that work for you.

So when a command line application queries a specific attribute, that attribute doesn't necessarily have to exist in the database. Instead, this piece of code will go out and grab it for you. And here's some examples of the fun stuff that you can do that's overlay madness. All right. So all kinds of possibilities that you have with this. There's about a dozen or so overlays that are prebuilt and command in OpenLDAP 2 3.

You can also create your own. Little bits of C that are just a couple of K. Here's an example of one that I really like. We've got a novel e-directory solution. It's LDAP based, but I want to put more information in it than what e-directory has allowed me to do. Maybe I get political push back on actually extended the schema. So I need to put a layer in between. I can put a couple of Xserve running OpenLDAP 2.3, I go in there, and I create and I add in a trance parent proxy.

And what the transaction parent proxy will allow me to do is it's a real LDAP proxy. All of my iMacs can connect to these Open Directory systems, which are going to proxy the LDAP requests back to Novel. However, when I make a right change, when I change anything on those OpenLDAP servers, it's cast locally and it's not pushed back to that novel system.

So I create a body of information on those two Xserve when my iMac's connected to the Xserve and query information, those L -- the OpenLDAP on those Xserves will first use that overlay. That information that I have changed. And then only get the remaining information back from the Novel system.

So think of this like the Cylinder of Destiny, but more cylindrical.

See, it really does work. All right. So instead of putting the augmented records in an entirely different directory and my client binds to both, I am actually putting a directory between my client and the main one, and I'm putting those augmented records, essentially, those hangs in there.

All right? So lots of possibilities with that. You're not going to get it out of the GUI, but it is part of OpenLDAP 2 3 and some of the stuff that you can play around with. What I'm really excited about is the jabber presence overlay that I wanted somebody on write. Because it was going to be a demo, but nobody did. And Nigel, I'm looking at you, if you're out here. All right.

So this is one of the cool things that you could do with an overlay. Right now if I look up a user record, I don't know if they're on line. And I don't know what their status is in jabber. And that would be really cool if I could do that. So now I can have an LDAP tool that queries a user record, does a standard look up for jabber, dash, status and attribute. That invokes this overlay, which would then go out and actually contact the jabber server and determine what their presence might be.

Well, this is kind of cool. You can have an Address Book application. Look up the user, you want to give them a phone call or something like that. You will now see their jabber status in there. And you will be able to determine whether they are acceptable for a phone call or whether you should just log into jabber and just leave them a message. This is the kind of cool stuff that you can easily add with an overlay. All right? Password server changes that we've got here in Leopard.

Tiered Admin support, like a said, with -- go hand in hand with that an OpenLDAP. You can use PW policy to set manually, or you'll be able to do this through the Workgroup Manager interface when you set up the tiered Admins here. Here's kind of an example of one of the PW policy commands that you might be able to use. And you're setting up groups there and allowing you to go through this. All right? And again, look for the man pages in Leopard when that ships for more information along these lines.

Tiered replications support. Again, we're tiers everywhere here. Open directory masters can replicate up to 32 replicas. And this is just a GUI limitation. Engineering believes that this could be a lot more. But we think we're going to give you enough flexibility just within the GUI that you probably don't need to do this by hand. And each of those replicas, those tier one replicas, can replicate up to 32 other ones. So real quick, how many total replicas is that?

1,057. 32 squared plus 32, plus 1. 1,057 replicas. We think that this probably should encompass the vast majority of openly directory replication needs for our existing customers. All right? Like I said, you can probably do more, but you shouldn't have to manually. We use a dif list now, so replication should be much faster.

Instead of replicated the entire Kerberos database now we're just doing changes. And we're setting it up so that even if your replication hasn't occurred, a replica will actually look to see if any changes have been made before fully denying an authentication. So we can make sure that we're as up-to-date as possible. We call this just in time replication.

So tiered replica madness -- we had to come up with a cool graphic that looks like this -- so one master to 32 replicas. 2 And each of those replicas can replicate out to another 32. So this looks like your replication structure here. A master of 32 tier ones, and up to a 1,022 tier twos.

This is what it looks like in the GUI. You're going to see a list of your replicas as before, but then you can click on that replica tree tab and you're going to get a list that looks like this, that allows you to see your actual replication tree and how it goes out there. So some new interfaces here in Server Admin to set this up and to work with this. Machine accounts.

You no longer have to have your machine accounts bound by your password server policies that you set up globally. All right. If you set up a global password server policy that says you have to expire your password every 90 days, you bound the machine to the directory, and that machine account expired after 90 days and we didn't give you a way of changing that, just all your directory services failed, now you can expire -- you can actually exempt your machine accounts from this. All right. So that's new to Leopard.

What I really like when you bind a machine into the directory, that machine will have a full Kerberos key tab. There is no more SSO Util that you need to do. Now all of your clients will have a full key tab for SSH and host records. You will be able to -- yes. You can sit down on the server, you can log in, and you can get single signed on, Kerberos, authentication to every single one of your client machines without having to do any extra work on your own except binding them to the directory. That's cool. That's cool.

K BC changes to the Kerberos, key distribution center. Curb row main support did not confuse this with cross realm support. A much, much different beastie. What we're doing it cross the main support is we're allowing Open Directory to leverage active directory for authentication. Specifically in relation to the magic triangle. And I'll give you an example of kind of how this looks.

Only one curb row domain is required in most situations. It's going to be an effective directory that's primarily the Kerberos domain. And we wanted to give you this to work specifically with things like teams, the wiki system, stuff like that. So here I have my iMac, it's my client. It's bound into active directory as we have done in the past. Normal way of doing that.

We also have an Open Directory system here set up just like the client. It's joined in active directory. Currently, if you do this some things don't work really well. For example, I can't use the active directory machine account that I generated when I joined active directory to authenticate to the Open Directory side of things.

So I actually have try to create an Open Directory account to get authenticated binding to both sides. That really didn't work. So now we're allowing you to use leverage Kerberos between these two. So your machine account that you used for active directory will also allow you authenticated binding via it's Kerberos taken from active directory into the open LDAP server on the Open Directory side.

All right? This should greatly facilitate curb row authentication between these two systems. So I can now set up the server as a magic triangle scenario, run a wiki server on it, my window's clients after getting an SSO ticket will be able to get all the services they're in. All right. So that's the new stuff with the Kerberos KDC . So let info -- dead.

Tears of joy. Not bad, huh? Not bad. And RADIUS support. So it's some very cool stuff that you have on there. All right. Also hopefully I gave you a few ideas about directory service deployments. Take it home; think about them. Lots of good stuff on there. Remember, Cylinder of Destiny!

All right. Now bring out Mr. Paul Suh. Thank you.

And I have a client where using open directory as a central identity store. A lot of places you have your Macs as clients, and then there's somebody else's central directory store where you're integrating your Macs. Well, this is the opposite. I want to show you some of the ways that you can take openly directory and use it as a center core and bring in other systems as clients.

So, just a quick profile of the company that I'm working with here. Quick International Courier. It's high priority air freight shipments. So -- medical samples, industrial spares, the kind of spares where every hour the machine's down -- that's -- you know, $100,000 down the tubes kind of thing. Legal documents that absolutely, positively have to be there -- not tomorrow, but today. That kind of thing.

All right. So -- multiple locations world-wide. So from London to LA. To cover it all. It's mostly Mac. All right. So here we have -- coming to the by and large is Mac-based. However, it's a company like many others that's grown by acquisition. All right? So they've bought other companies and the other companies have various heterogeneous systems that have to be brought in.

So -- what do we want out of this? Right? We want to decentralized a data management system. So we already had user accounts in three places. Just going into this project. Right? Had Solaris running in -- the user accounts on Solaris, had an IBM university database running on top of that. Another set of user accounts. And we had yet another set of user accounts in first class.

And so you know, the very manual process -- every time you hire a new employee, every time you bring a new vendor on board. Whatever. Create one here, create one there -- create a third one. But it's only going to get worse. Right? So -- we want to implement network and portable home directories. That's going to be the new Open Directory, that's going to be a fourth place.

And there's a New portal system being developed in chrome right now, and that would be fifth place. Okay, time out. This is not going to work. So some general requirements just from the way the company's organized, this is a company that does 24-7-365. They are fanatical about up time. Two of everything. At least two.

Five nines up time is -- they really need it. How many of you have encountered a situation where is it -- the customer says, I've got to have five nines up time. I've got to be totally reliable. And you tell them how much it's going to cost and they say -- oh, well -- Nah. I don't think I want to do that. They're serious. What does that really mean? That means six minutes of down time per year. Right? That's serious.

So -- so specific requirements things do need to be integrated in. I mentioned it just to get it in there. Some Mac and windows client systems -- I'm going bring those in. Solaris 9, and IBM universe database. Let's bring those in. First class e-mail and collaboration server, again, has to be brought in. They have Web objects applications. Actually, running Objective-C WebObject applications, believe it or not.

And the plone portal that I mentioned. So a lot of different things that have to be brought in and integrated. So, what we thought going in, right? So -- anyone else do a little study -- try and cover their -- the bases, look what's going on. And we thought, okay, we're going to need to customize the Open Directory scheme. That's not so bad. The Open Directory is very flexible. Shouldn't be a huge deal. All right.

Probably you need to write some custom scripts and adaptor code. Right? There are probably bits and pieces here that aren't quite going to fit. We have to build some sort of little connector to make things fit. And so what have we learned so far just to give you a taste? We thought wrong.

So far, I mean, no scheme of modifications so far. This is a work in progress, like any other large IT project. You know, you take it in stages, step by step by step. And we're only part way through the process. We'll probably encounter other things as we go. But so far, no schema modifications.

Very little custom coding work. We have wrote a couple of little scripts, but it was just one-time stuff. Nothing serious. So -- what to take home. What I first learned how to do presentations my mentor said, Paul, give them a list of three to five things that you just want people to take home.

So -- my list of take homes here. You need to configure your client systems for the openly directory LDAP tree. Right? This isn't so bad. Most systems that talk to LDAP understand that there is no standard LDAP schema and they're pretty flexible about it. You can use DS import. The command line tool as a bridge.

It's a very handy little bridge. Especially because you can use it in scripts that actually come from other systems. You can use LDAP authentication to provide authentication to just about any system. But the nature of Open Directory makes it more useful than just sounds. You can use Kerberos to enable single sign on. It is Kerberos -- full Kerberos MIT KDC.

Well -- and in a high availability environment such as with third party systems you can use low balancers. So let's look at the system architecture here. So in the middle, it's a data center in New Jersey. Got openly directory master end, Open Directory replica. Right? So the center master, center replica. For the Mac OS X systems in various remote offices we have replicas, remote replicas to consult down on land traffic. Right? So far so good.

We have a Solaris 9, and universe database also running in the data center. First class servers are actually running on Windows . Web object (Inaudible) running on Xserves. These are all in the -- data center in New Jersey. Between these data systems, however, these non Mac OS X systems, I should say, and the master and replica, they have balancers. These are actually from -- we're using ones from Coyote Point.

Just a quick review here. Open Directory server components. Obviously we talked about OpenLDAP, just want to remember, we have the integration starting with LDAP. Because that's what most systems know how to talk to. However, you've -- remember that because of the integration you can get to the password server and KDC through the OpenLDAP.

Right? So -- first stage of things the user identification. So this is figuring out what -- how to identify users. Client systems need to know about the search base. Right? So here CN equals users, DC equals OD master. Example DC equals com. Right? So you're following the tree down into where the users are located. Ditto for groups. Right? So pretty standard if you know the OD server side pieces. So, it's a little demonstration here for the user identification. All right. So if we can go to Demo A please?

Okay. There we go. All right. So here we have Workgroup Manager. A couple of users. And you know, just user one, user two. Fairly standard sorts of things. If we look at it here in the Inspector you can see what the users look like. And these are the native attribute names for the underlying LDAP.

However, this isn't the way that a third party system would see this. Right? So let's look at it using another tool. Let's look at it using LDAP. Here I set up LDAP to look at the Open Directory. And as we scroll down here see that we're starting at the top of the search base. Distinguished name looking like that. If you can see that -- unfortunately I can't make the LDAP any larger.

If you come down to users, click that open, and here's user one. And you can see the attributes there are for that user. So you can see we're following down this tree from the root into users, into the user's actual name. And has natural distinguished name here. So, how do we actually make it work? Well, here I have -- this is actually a Solaris running in a virtual machine. And just to show you it's -- you can use the I.D. command.

Doesn't know about user one. All right. Now there's a command on Solaris called LDAP client. And I have a text clipping here. And this is a command -- yeah, it's complex. But it's actually fairly straight forward. (Inaudible) a default search base. All right. So that's pretty straight forward. Search base for users, for the passwords.

Here. This just gets you the long name doing the right thing. And this is search base for the groups. And the server to go to. Right? So it's actually fairly straight forward. Yeah, it's long. But it's nothing to freak out about. If you just take it step by step. So -- you can watch it go.

Okay. And now we can see that it knows about user one. All right. So knows that its -- I.D. is 1025. Go back to Workgroup Manager and see that user one in fact is you did 1025. Knows group 20. And knows that group 20 is stacked. Right? So, that's user identification.

Right? Realize that this is just identifying the users. It doesn't give you user authentication yet. All right. So we can go back to the slides please. So, we need to -- any kind of situation in this case not a green field. You are not setting up the company from scratch we had to integrate existing identity stores.

All right? So -- console date users from existing stores. And this is an ugly process any way you slice it. You know. You've got user John Doe who's John D. On this system, J. Doe on some other system. You have to figure out how they all mesh together. Somebody has to go through and, you know, use your favorite set of tools to figure out how to get a consistent set of users and groups out of these things. All right? So TextEdit, BBEdit, Excel -- whatever. Name your favorite poison.

All right. So -- once you've got it together you can import the tools, import the users using DS import. Right? Command line tool. Works really well. Works both for the initial import and also for the -- for maintaining across time. Right? And that's important because you are going to need an interim process for creating and managing users.

You set things up, get things going. You have at some point you're tied in different systems. But other systems are still not tied in yet. You don't want the big bang -- try to do it all at once. A sure recipe for failure -- right? One of the nice things about DS import is you can specify the user's password as part of the DS import file. In our situation at least one of the systems actually stored the password in a recoverable form, which made it easier to give users at least a password for consistency that they already used.

Right? So first thing we want to do is specify the user record type. So there is two lines in that DS import file that you might see. If you want to see the full -- an almost full listing of all the different types go into Workgroup Manager, select a user, select export. And you will get this huge list of different attributes that work with manager will export. And specify a number of columns.

In order to specify a password in the file, one of your columns needs to be DS attribute type standard off method. And the value you want to put in there is DS -- DS off method standard back slash colon DS off text off clear text. We need the colon in there because that's part of the name of the actually value.

But then you have to back slash escape it so that DS import doesn't treat it as a column separator. After that, you specify the column name DS attribute type standard colon password and the actual clear text password. All right? So -- a little demonstration. Let's actually try that. I can go back to -- demo A, please? Okay. So here's a -- the text file.

For an import. Bring that up a little bit here again. So, exactly the file I had before except I have given it a slightly different password here. There's this column, the colon delimited values. And let's see, where is my Terminal window. All right. So I have a command here, Set Up. So here's the command. DS import.

And would it -- the file is going to be imported. The node that it's going to go into is going to ignore dupelicates, and the user that we're going to authenticate as -- this needs to be directory administrator account. Notice I don't have to sudo this. This is not a root thing, right? Because you're authenticating as the directory administrator. Put in directory administrator password. And it's read in. Go to work book manager. And refresh the list of users. Now we have another user there. And we come here into our Solaris system that we tied in.

Now notice about that Solaris -- that new user that was not in Workgroup Manager before. All right. So DS import -- real easy thing to do. Another thing to note is that this kind of file is really easy to generate as part of a scripting system. All right? So as part of generating new user accounts, the H R system can script this in Open Directory. And that's one of the things that we are in the process of implementing right now. All right.

So that the HR people just come in, a lot of default values will be filled in. And poof. The user gets created automatically instead of having to go from system to system to system, and create the users over and over again. Right? So you can go back to the slides please.

All right. So LDAP authentication. Use this as your base for integrating other systems. How does it work? It's essentially authentication by a non anonymous bind you connect via LDAP to the OpenLDAP server. And you give it a user name and password. And if the OpenLDAP server says that's good, user's authenticated. If it comes back and says no, I am not going to allow that bind, the user's considered not authenticated.

Well the key thing to remember is that this is an indirect use of password server. Open LDAP is going to call into the DS APIs and eventually talk to the password server to do that authentication. This gives you all the benefits of open directory in terms much managing the password.

So resetting passwords, expiring them, lengthening and complexity limits, et cetera, et cetera. Right? So it's a quick demo of actually doing LDAP authentication. So we can go back to the demonstration please. So -- all right. So right now try to connect to the Solaris server using one of the user accounts that we tied in with the OpenLDAP, with the LDAP client command. It's not going to work.

nope. Not going to let me in. Even -- I've tried that three times because I am a horrible typist. So -- not going to work. Hmm? Caps lock. I checked that. Check caps locked. So what do we need to do? Well, a couple things. First thing we need to do is do another LDAP client command This is slightly different from the other one. I am sure you can spot it easily.

It's actually one change. I've added a -- how many -- let me tweak the window. Maybe you can see it a little easier. There you go. Add a serve authentication method saying PAM LDAP. All right, so PAM LDAP is going to be a simple L dot bind authentication. So if we do that, spinning the gears.

Does the same. And there we go. But wait, there's more. we have to make one other change. How many people here are familiar with PAM? Applicable Authentication Modules? A lot of places use -- a lot of UNIX systems use PAM. And we need to make a slight change into the PAM configuration.

So this is the PAM -- let's say PAM dot com file. And (Inaudible) SSH I am going to go down to -- to the other. And we're going to make just a minor change here. And conveniently, I have the thing specified. So we're just going to -- it says we're going to be adding here the PAM LDAP module to the list of authentication modules. Right? If we do that, come back here -- what happened there?

I did save it.

- There we go. And there we are.

We're now able to authenticate as a user from OpenLDAP, from the Open Directory master, into the Solaris system. All right?

And -- let's see. So here, notice that the -- since I didn't bother sending to the home directory, coming from Open Directory, it just -- home directory's 99. If you actually put in a home directory, one of the things I should note for you is that you probably will need to set up some links on Solaris or whatever to other systems so that the home directories end up in the right path. Because you -- for your Mac OS X users they're going to be in the usually network servers, server name, volume, yadda yadda yadda. Right? So, we can go back to the slides please.

All right. So LDAP authentication. So -- you can use Kerberos for single sign on. So it's real easy. You can use the ED MIT dot Kerberos file that's on Mac OS X. It's the exact same format as your standard care B 5 dot com file for all the UNIX systems.

You generate your principals using Workgroup Manager and Server Admin. But then you just -- instead of using Server Admin on the client server, on the service server to get the user principals out of the Workgroup Manager record, you just use K Admin, or K Admin dot local to export to a key tab. Copy all those files over into the server, put them in the right places, and generally at C , tier be 5, or something like that. And turn on the Kerberos authentication of the and it works.

Right? Unfortunately, the demo Gods were not being kind. It's only worked the last 100 times I've done this, but I was able to actually get the demo system to generate key tabs. It was a problem on the openly directory side for some reason. I am not sure why. So, we're going to skip this demo. Insert emergency demo joke here.

So -- last piece of the take home -- open directory failover with load balancers. All right? Remember that openly directory replicas are noted in C equals LDAP replicas, scenics equal configs, C (Inaudible) yadda, yadda, yadda. Mac OS X systems know about this. They'll look at that list, they'll fail over to a replica automatically. All those systems will not know about these. Will not know to failover one or the other systems.

So -- so you can use a load balancer to intermediate. But then the load balancer itself becomes a single point of failure. Remember, this is the company that is serious about five nines Right? So what do we do? Put not one, but two load balancers there. And the load balancers themselves are Coyote Point 480s.

Essentially have IP fail over, just like Mac OS X has IP fail over. One's a primary, one's the alternate. The alternate will be the primary heart beating each other. And when the primary fails the alternate picks up the IP and keeps on trucking So you need to set up ports 389 TCP and 636 TCP. One's for non SSL, the other's for SSL connections.

Interestingly enough, you don't need to put your Kerberos authentication through of the load balancer. Why? Because the edu.MIT dot Kerberos file already lists the various KDCs in it, and Kerberos authentication particle is smart enough to go to an alternate KDC. One thing you need to either turn off what's called spoofing, or use what's called full proxy depending on your load balancer. Because Mac OS X systems need to connect directly to the Open Directory masters and replicas.

They should not go through the load balancers. Because then they'll try and look at the list of available replicas that's in the LDAP and they'll get horribly confused. So Mac OS X systems, they go directly to the masters and replicas. Other systems that are not aware of open directory, those go through the load balancers.

A cheap way to do load balancing, which is not as reliable and may give you some intermittent failures is to do round-robin DNS. So that's an alternative way of doing load balancing across Open Directory. However, really good high availability, you do want to use a hardware load balancer.

So -- summarizing this -- the process was a lot easier than we thought. We spent a lot of time going hmm. We've really got to get this right. Yeah. It's not that hard. Most client systems are pretty flexible about things. You just have to feed them the right paths into OD.

The addition that we added was the hardware load balancers. And standards and integration made this a really great choice, right? Because we need them for the home directories anyway. And because it's all standard spaced integration, happens easy. And because password server and KDC are tied into OpenLDAP, it all just works. There's no step three.

All right. So looking to Leopard, looking forward. I'm definitely interested in the VP -- RADIUS for VPN support. Right now the VPNs are being managed entirely separately. Not everyone has VPN access, and -- but as there are more users going into home offices, VPN is going to becoming -- managing the VPN is going to become more and more of a burden. Also the tiered replication to support in more locations. We may not be hitting the real 32 limit per se2. But having -- the way that the WAN links run it may be actually easier to do some tiered application rather than running everything back to the data center.