Welcome everybody to the What's New in Directory Services session. I'm Nicole Jacque and I'm an engineer with the Directory Server Team at Apple. And what we're going to talk about today is we're going to talk about what's new in Directory Services, both on the client side and on the server side. And we're going to get started with just a quick overview of Directory Services in general, for those of you that are, maybe new.

And then we're going to talk about Directory Services on the client. We're going to spend a little time, particularly on the Active Directory plug in, because this is a very popular plug in with customers. How many people here use Active Directory? Like a whole forest of arms here, alright that's why we're spending a little time on it.

Then we're going to talk about Open Directory, which is the server side of OS X's Directory Services. And then we're going to wrap up with some best practices, because I always like to leave you guys with a little bit of practical information, stuff that you can take back with you to either use right away with Leopard, or to help with your plans for Snow Leopard deployments and so on.

So let's get started with an overview of Directory Services. So we're going to start by talking about Directory Service on the client side. Directory Services, basically its main job is to be the translator between the OS, Mac OS X, and some data store somewhere that has records - things like users and groups and computers, and other types of data that you might need to use.

And the way that it does this is it sits as this layer that the operating system can call into, either through different API's like the LIB system API's, the Directory Service API, there's a new API on the Open Directory framework. And Directory Service itself is a daemon that runs, and so all these API's talk to Directory Service.

But Directory Service still has to get all this information out of these data stores that are out there somewhere, and these data stores can be flat files sitting on your computer, they could be some directory server out there somewhere, either an LDAP server, an active Directory Server, maybe eDirectory, iPlanet, something like that. So because there's so many different possibilities out there for where this directory data could be, we have a plug-in architecture.

So Apple provides plug-ins for a lot of really popular directory storage. So for example, we have DS Local which is our own local flat files. We also have a plug-in for the traditional UNIX flat files, so the files that you would normally find in etc. We have an LDAP plug-in and that talks to both our own Open Directory Server, but also at any third party LDAP servers that are out there.

We have an NIS plug-in, and we also have Active Directory which is, you all saw from the hands before, is really popular. Now if all of these plug-ins aren't enough, we also have the option for third parties to create their own plug-in, and there's a number of third parties that have done that; things like the Kanaka plug-in for eDirectory, Thursby's ADmitMac for Active Directory and so on.

So that's the client, but now in the server we have an app, what we call the Open Directory server, and this is Apple's Directory Server. And it's really made up of several parts. We have an LDAP server, we have the password server, and we have an MIT KDC. We also have a Radius server that can talk to these.

And to talk to the Directory Server, you can use our Directory Service client... which is great, but just in case you have other clients out there for example, a Windows machine or something like that, because we have a standards based Directory Server, you can talk directly to the server through any of these standards that we support. So you can talk to the LDAP server over LDAP, you can talk to the Password server for authentication using SASL methods. You can talk to the KDC using Kerberos, and you talk to the Radius server using radius. So it's very standards based.

OK, so that's our quick overview and now we're going to go ahead, we're going to dive into what's new in Snow Leopard. So starting with the client, the Directory Service client... what we've done for Snow Leopard is basically you heard Bertrand say we weren't focusing on new features.

This was a chance for us to do sort of, clean up to do evolution of our code. So our changes for Directory Service are basically we did a lot of clean up of our code, got rid of some old stuff that had been sitting around for a while, but we also did a lot of work on making things more efficient; working on data structures, working on things that maybe could be made faster, or things that could be just made more efficient in general. And we want to basically improve our performance for Snow Leopard. And we also wanted to work on fixing any bugs that had been sitting around.

We do have some other changes that you'll notice right off the bat. So how many people are familiar with Directory Utility, which is how you always configure directory... yep, OK everybody's seen that. So you may have tried to look for it in Snow Leopard, and you said huh - it's not there anymore.

It used to live in applications, utilities, and it's not there. So what we've actually done is, because Directory Services is now such an important part of the operating system, we've moved into system preferences like all of the other important preferences for the operating system. So if you go to the Accounts pane under Login Options, we now have the option to join a network account server.

And if you click that, you'll get the option to enter the name of a server, and we added some cool logic so as you type, we will actually detect what type of server this is. So if it's an Open Directory server, or an Active Directory server, we'll give you the right panel depending on if you need to provide credentials in order to bind to it.

And then once you've bound to it, you'll get a little status display that gives you the green or the red to tell you whether or not that node is working. Now some of you may have some very complex servers that you need to connect to You may have complex configs. You can still use directory utility, it's actually still around, it now lives in /System/Library/CoreServices. You can either go directly to it or there's a button inside of system preferences that will take you right to directory utility.

We also have some changes that we've made under the hood, things that you're not going to see in the UI. And the first thing, this was actually a pretty major undertaking, is you may have heard in the keynote or in Bertrand's state of the union, some talk about something called GCD, or Grand Central Dispatch.

And Directory Services has actually completely adapted Grand Central Dispatch. Directory Services has a lot of different threads, it has a lot of stuff going on at any given time. And Grand Central Dispatch was the perfect technology to help us really sort some of that out, make it more efficient with how all of our threads were working.

So not only does Directory Service use Grand Central Dispatch, it uses pretty much every part, every part of the Grand Central Dispatch API. So this is really an example of us eating our own dog food here. Another change, how many developers here remember the Directory Service API? Any developers? OK, it's deprecated now.

No cheers? OK. So if we take that away, we've got to give you something else to use right? So we've introduced a new API which is the Open Directory framework, and if you're interested in this I have a session tomorrow morning on this, and it's really a very nice, easy to use API; something that even if you're not a hard core developer, maybe you are a system admin that's sort of getting into programming, it's something that you can use. So I would encourage anybody that is even slightly interested in programming with Directory Services, come to my session tomorrow morning.

Unfortunately again, it's in the morning but... come take a look at the Open Directory framework. And another change that we wanted to make for Snow Leopard was to improve our caching, because we have a lot of things going on and performance wise, something that takes a big hit is if we have to keep going out to the server, keep reading flat files and stuff like that. So we've put a lot of work into improving how we cache information in Directory Services.

And finally, previously Directory Services handled not just Directory Service records and stuff like that, it also handled all of the DNS look-ups on the client. It made more sense though, when we looked at it, to actually just let MDNS responder handle all of this. There was really no need for DS to be involved, so that has all been moved over to mDNSResponder.

OK, so those were the changes for Directory Services in general. But again, since there's a lot of people using the Active Directory plug-in, let's talk about what's new with that. So first of all, one thing that we wanted to do was fix bugs. But beyond just bug fixes, we wanted to make sure that we were supporting common configurations that our Active Directory customers use.

There's a lot of really complex forest configurations out there that people can have, things like disjoint forests, non hierarchical forests, and all kinds of things in between. So we wanted to try to make sure that we were supporting the configurations that were most common with our customers, and we'll talk about a few of these. Also Microsoft has a new server version out there, so Window Server 2008.

We needed to add a little bit of support for that. And then we also wanted to, just in general, work on stability across the board with the Active Directory plug-in. And because we have a lot of laptop users, people that use the Active Directory plug-in and use it with mobile accounts, portable home directories where they're going on the network, off the network. We wanted to make sure that their experience was as good as somebody that was on the network all the time. So we really worked on it...

Apparently that's important.

So let's talk about... oh, I gave it away! OK, so 1 big change, and judging from the applause here

... we now have password expiration notices at login. So 1 thing that we had a lot of requests for is people wanted to be able to know, hey my password is going to expire in a certain number of days, and I don't even want to know that it's going to expire, you want to be able to maybe go and change it. That sort of made sense to us too, so we've actually put that all in login window, so as soon as the user authenticates they will get this notification.

They can change their password right there, or they can change, or they can opt to bypass it and just continue logging in. So another change that we've made, and this falls under the category of supporting some common configurations. Turns out we have a lot of customers that are in what we call a disjointed Active Directory configuration. So this is where your DNS name for your host name doesn't match the DNS of your Active Directory domain. Turns out a lot of people had this, so we actually have built in support for this.

We will actually detect that you're in this configuration, and we'll say oh - hey your host name doesn't match your Active Directory domain name, we're going to go ahead, build your key tab with service principles for both. So you will actually get a key tab with service principles with your host name, both what it is currently, and what it would be if it was in the Active Directory domain.

And again, no fancy configuration required, it will just do this automatically. And finally, we've improved our support in Workgroup Manager for editing things back to Active Directory. So if you've extended the schema and you have admin access to Active Directory, we've made the behavior of Workgroup Manager better for editing these records that already exist. We've also added support for editing group information in Workgroup Manager, so you can now add people or take people out of an AD group.

OK, I guess a few of you wanted that. And then also support for creating computer lists.

And we have a few other changes I just want to go through real briefly. You've heard me talk, if you've been to 1 of my previous sessions, one of the best practices that I had to tell you was, if you are using Windows 2003 R2 or greater on your Active Directory domain, I said well you should go get either you or get your Active Directory admin to go and index the Mac address attribute, because it's present in the schema, but it's not in the computer object class.

And so we would say oh, we're going to bind to the domain, let's see if the computer count is there, let's check for the Mac address, and we'd send the query out... and instead of the Active Directory coming back and saying oh - we don't know anything about Mac address, it says oh - I do have an attribute called Mac address, I'd better search every single object in the directory.

That's a little expensive if you have a few million records. So you had some very slow buying time things going on. So we now have added logic to the binding process. We will actually detect whether or not the Mac address attribute is present, and whether or not it is part of the computer object class; because it could be. If you've extended your Active Directory schema with our attributes, then Mac address will be in the computer object class. So it will detect if that's the case.

If it is in the object class, we'll go ahead and do the query. If it's not we skip that query, and you don't have to worry about it bogging down and creating all these expensive searches on your Active Directory domain. Another change that we've made is we've added differentiation for user and contact records.

So people that had exchange for example, you had maybe a lot of contact information in your directory. Previously we could confuse that with user accounts, and so sometimes you'd get conflicts between users and contacts, so now we know the difference. We've also added support for IPv6Active Directory domain.

So if you're a fully IPv6 AD environment, the AD plug-in now works for you. We've added some more support for hierarchical domains, in particular domains that have more than 3 levels of hierarchy, so you can now... previously you only have like at 2 levels of hierarchy, now you can do 3.

And we've added support for Windows 2008 domains, and this is primarily an area where we had to get some support from the MIT Kerberos libraries, so that has all been worked out so it's all compatible with Windows 2008. And a few changes that aren't in the plug-in itself but are in OS X server. We had 1 to make in OS X server. We know you might be using Active Directory, but still want to provide services to all of these AD users.

OK, so we thought we should try to make this a more smooth user experience. So 1 thing is when we first shipped Leopard, I spent a long, long time in my session talking about how to create augment records, because there was this attribute called Services Locator that you needed to have if you are going to use the Wiki server or the iCal server. And AD users didn't have it.

So the way to do this was you had to create an augment record for every user that you wanted to be able to use the Wiki server or iCal server. So it worked, but it really wasn't a lot of fun to have to do that for every user. So for server, for the Wiki server and the iCal server, we have totally eliminated the need for Services Locator, so you do not need to create augment records.

Augment records by the way, do still work. You can still create them if you have other reasons for using them, however there's no need to do this just right out of the box. You can turn on Wiki server or iCal server and use it with AD users.

And then another thing that we've added is we had some services where their authentication methods were basically either Kerberos, or cleartext for Active Directory users. This was because of the authentication methods that Active Directory supported And we've actually added another option for a couple of these for Podcast Producer and iChat. You now, instead of using cleartext, can use a specially proxy version of Digest 75. So basically you don't have to be sending these passwords in the clear if you're not using Kerberos.

OK, so we've talked about the client side and we talked about Active Directory we're going to switch gears a little bit. We're going to talk about the Open Directory server. So you may have heard, how many went to the state of the union address for server? OK, you guys may have heard for server we weren't limited by the "no new features". We actually went ahead, we put a bunch of new features in.

So we have a couple new features to talk about, but we also had as a focus... performance and scalability. We wanted to really increase the way that you could use our Directory Server with large numbers of clients, lots of connections. And then we also wanted to have better support for working with other directory servers, because we know a lot of people want to integrate with Active Directory, and so they use a configuration we call the Magic Triangle and we're going to talk about this more later during the Best Practices session.

But basically we've added better support, and we kind of considered this to be sort of a more standard config that we consider as a common config that customers use, and that we test with. So 1 change that you're going to notice right off the bat, is during server set up. So you install server, you go into server set up, and you'll notice that we've changed the options that you have regarding Directory Services.

You're welcome. Whereas before we had some configurations that were called standard, workgroup, and advanced... and Xsan, thank you OK we don't want to forget Xsan. And these kind of lock you into kind of what we called silos. They kind of locked you into particular set of services and configurations, so we kind of removed those connections to these set ups. But we've retained these 3 basic Directory Service set ups.

So Create users and Groups just sets up a basic Open Directory master. Import Users and Groups, is going to set up an Open Directory master but also give you the opportunity to bind to some other directory server. And then you're going to get your users from that directory server, and you're going to use the Open Directory server for things like non-user records, maybe groups add users from another directory to those groups in your Open Directory master. Or just config records that are used by different services. And finally, Cconfigure Manually... well pretty much as you'd expect, you manually configure it. That seemed to make sense. Another change is with SACLs, or Service Access Control Lists.

This is something that we added in Leopard I believe, but we've changed where you configure this. This is so important and we really want people to adopt using SACLs, that not only do we turn them on now when you set up the Open Directory master during service set up, but we want to make it more prominent in server admin.

So it's now right up there on the top menu bar. And this is something that in testing and in people using Snow Leopard server, so far, something that has occasionally caught people by surprise because it was the same way in Leopard, but they kind of forgot this. By default, unless you do the manual configuration for Directory Services, SACLs are turned on.

And so users, if you create them in server preferences, they get automatically added to the SACL lists for whatever services you enable them for. Where people get caught though, is if you use Workgroup Manager because this is considered sort of a more advanced configuration tool, it doesn't automatically add the users to the SACLs, you're going to want to set up some custom configure.

So just keep in mind that if you add users through Workgroup Manager, you still manually need to add the users to the SACLs yourself. And we've actually added a little warning panel in Workgroup Manager just to sort of remind you of this, because this was a common thing that people would just, they'd forget and they'd be like why aren't my users able to log in, and it was just they hadn't been added to SACLs.

We also, if you choose the custom config, we now give you the option to opt in or out of turning on SACLs. You can always turn SACLs on manually yourself at any time, or turn them off, but we actually give you that option during server set up now.

Another server set up change, in Leopard you may remember that the admin account that you're asked to set up during server set up, well that would get created in the Open Directory node. And then we would create sort of a backup admin account called locadmin, or Local Administrator, in the local node.

The problem with this is that if something went wrong with your Open Directory master, you suddenly lost your main admin account and you had to remember, oh yeah there's this backup account that I can use and login. So we reversed this for Snow Leopard. The account that you create during server set up gets created in the local Directory Service directory, and then we create a user called diradmin, or Directory Administrator, with the same password in the Open Directory master.

So it's just the other way around. Alright so now let's get into sort of the "meat" of the Directory Server. And as we talked about before, there's 3 main portions of our Directory Server, and one of the most important ones is LDAP, the LDAP server. So one of the changes that we made for Snow Leopard is we've upgraded to a new version of open LDAP, we're not at 2.4.11.

And between our upgrade to the new version of open LDAP, plus a lot of optimization and performance work that we've done, things like optimizing our data structures and just cleaning up code, we've gotten a 2X read performance improvement. So your reads to LDAP, which is something like 99 percent of all of your LDAP traffic is reads, are now going to be twice as fast. We've also switched from using slurpd to syncrepl for handling all of the LDAP replication.

But the modern way of doing the LDAP replication. Also previously in Leopard and before, you're always hard coded to a limit of 1,000 connections. This was hard coded, that was it. You got to 1,000 connections, you hit the wall. And like I said, one of our focuses for Snow Leopard was we wanted to increase our performance and scalability, and lots of people out there have more than 1,000 clients that they need to be able to talk to the server.

So we've actually removed that 1,000 connection limit, and in fact we've tested with over 8,000 connections, and the server basically handled them very well, hardly even noticed all the connections. Of course depending on what kind of queries you're doing, your mileage may vary, but basically it can handle 8,000 connections or more. The limitation here really is just based on how many file handles you want to have open.

And your rule of thumb here is that each LDAP connection is 1 file. So we actually let you set this, so if you want to change this value by default, we have it set to 8,192... files open. And keep in mind there's a little bit of overhead here, slapd needs to have a few files open for connections to the database, and just things that it's doing internally.

So the number of files is just not exactly equal to the number of connections that you're going to allow, but it's very close. So by default we have this set to 8,192, but you can go ahead and change it to whatever you want. You just need to change the slapd plist that launchd uses, so in system library launch daemons. And you can configure this to be basically whatever you want, depending on how much of your server's resources you want allocated to LDAP.

This really gives you a lot of options for scaling up your Open Directory server, to support a larger number of clients. But we also wanted to make some improvements in the area, and not just the performance but reliability. And when we are talking about reliability with LDAP, we're basically talking about what's going on, on the backend. And our back end database for LDAP is based on BDB, and so we've updated our version of Berkeley DB. Thank you.

We've also done a bunch of toning to get better performance and to get better reliability out of the Berkeley DB database, and we've also started using f_fullsync. So when you make a change to the LDAP database, not only does it get flushed out to disk, it gets flushed out to stable storage which means it's not sitting just cached somewhere, it's actually written out on the disk, it's there so if something happens it's recoverable.

Now the problem is you always have this fight between reliability and performance right? Things that are reliable are usually not quite as fast. And again, we have that here. So f_fullsync, it's great for database reliability. It's great. But the problem is, because you have to do all of this flushing all the way out to disk, well it's going to be a little slower and that's pretty much to be expected. The good news here is that most of the time with LDAP, you're just reading. So there is no performance hit. Your only performance hit is when you are actually writing.

So most of the time it's not a big deal. But there are times when not only are you going to do some writing to your LDAP database, but maybe you're going to do a lot of writing to your LDAP database. And this is something like you're importing all of your users, or you're importing a lot of records, making a lot of changes, some bulk user changes or bulk record changes.

And for cases like that, it'd be handy to be able to control this fullsync behavior. So we actually give you this ability in the slap config command line utility. So we have a new option, slap config set fullsync mode, which you can set to either yes or no. Yes is basically normal operation mode, so fullsync is on, this is your best setting for the best BDB reliability.

You can also set it to "no" which means that fullsync is going to be turned off. This will make your imports faster, but you don't want to run for any great length of time other than when you're actually doing your imports, you don't want to run with this set to have fullsync off, because then you lose all of your database reliability improvements that you got with the fullsync.

So just keep in mind, go ahead, use this option when you're doing your bulk imports; but then don't forget after you're done doing your imports, go back, turn the fullsync back on. And it really does not give you any benefit to be running under normal circumstances with the fullsyncs off, because there's really no performance benefit, because like we said, most of the time you're just doing reads to LDAP.

So you're not going to see the performance benefit. And if you run with fullsync off, you're putting your data at risk, and nobody wants to do that. So just keep in mind if you turn fullsyncs off, turn them back on again when you're done with your bulk imports.

OK, we've talked about the LDAP server. Now let's talk about Password server, and this is an area where we have actually added some new features. And these are features that we added based on requests from customers like you guys. And the main feature that we got requests for was actually 2 parts. Had to do with users changing their passwords.

The first thing that people wanted was they wanted to be able to, when a user changed their password in Open Directory, be able to sync that to some other directory server; maybe a Novell eDirectory server or some other third party LDAP server. The other thing that people wanted to do was they wanted to be able to filter the password that the user was changing it to. Now we do provide a number of policies in Password server that let you control, for example, how many characters the password has to be, whether it has to require a letter or number or special symbol, things like that.

But some people have some very specific requirements, especially customers in the government space; people that have very, very exact requirements, and if they don't follow them they get people in places like the CIA a little irritated with them, and they don't want that. So they want the ability to create password filters that are whatever they want them to be.

So we said, sounds like a good idea.

Now as part of this, like I said, you're going to create a password filter that's whatever you want it to be. Well that means you're going to have to do a little bit of work here. We're going to provide you the hook, but you're going to have to provide and do a little work to actually implement some sort of logic that says what password policies that you want.

So there will be some work required on your part, basically you're going to have to build a little tool which could be a script, or could be just some... a binary, however you want to write it. Basically you're going to write a script, could be as simple as a shell script, could be whatever type of tool you want, you could do it full blown little binary in C or shell script.

You just need to install it in Library/Password Server Filters. And what this tool needs to do is basically be able to handle 2 different arguments that could be passed to it So the first argument is the preflight argument. So this would be called, your tool will be called with -p and this means that a user is attempting to change their password.

In that case, what you're going to get is an XML, sort of a plist basically, that's going to have the user name, the password that the user wants to change to, and then what type of a user they are. So whether they're an admin user or a standard user, this is going to get passed to your tool on standard in, and so then you can say hmmm... you can apply whatever logic you want to it.

If you like the password and you think it's OK for them to change it, just exit 0 and Password server will go ahead and let them change their password. Now if you want to reject this password change, just exit with anything other than 0. Password server will see this and say oh - I'm going to reject this password change, and the user will get the rejected password change... little blurb that they get when they say, you know, your password does not meet the requirements set by your admin, please talk to your administrator for more information, and so on.

You can also use this to synchronize the password out to other directory servers, or other places, because once the change has actually taken place, will call your tool with the -C or the change argument, and you'll get the same piece of XML - the user name, the password, and the standard or admin user type. And then you can do whatever you want.

So you could pass this information off to some other directory server somewhere, wherever you want to send it. Just keep in mind you're dealing with user's passwords here, OK? So whatever you do, just do it securely. Use SSL, use Kerberos, please don't send user's passwords around the network in clear. OK, so that's our feature for Password server.

We also have a radius server, and we've upgraded this to the new version of FreeRadius, so we're at 2.1.3 now. And we've added as a feature, we've added the ability to authenticate Active Directory users through the Radius server. And this is actually something you don't need to do any special configuration for. If you're bound to Active Directory, your Radius server will actually change it's config so that it can actually do the authentication against, not just any open directories that you might have, but also any Active Directory users.

And a final thing that we've added as a feature in Snow Leopard, is we have a lot of cases where you set up your server, you think everything's good, and you're never going to change the IP number or the host name, and somewhere down the line your network changes, maybe your company changes.

You need to change that host name or the IP number. So server wide we've put a lot of work into making the server very resilient in the face of IP and host name changes, and actually I'm going to... in our Best Practices section, I'm going to talk about the exact process that you would want to go through for an Open Directory master if you need to change its host name or IP number. But after you've done all of that, you've got this whole directory full of data - user records, mount records, all kinds of data that might still have references to the old host name.

And it could be a real pain to actually sort through and find all these records, change them over to, for example, change them over to a new home directory server and so on. And this can happen, even if you're not changing that host name or IP number on the Open Directory server itself. Maybe you've just changed the host name of your home directory server, or maybe you've added a new one. And so all the users that used to have home1.domain.com are now going to be home2.domain.com. So we've actually given you a new tool.

It's called ChangeDirData, it's a PERL script, and basically think of this as like SED for LDAP. OK, it's basically find and replace. So you can say specify server, and you can specify credentials for a directory admin, but then basically you're just going to say OK the old value, for example, oldhost.domain.com. And then what you want to change it to, so newhost.domain.com. And you can also specify what record types you want to edit. So maybe you only want to change information in user records, or maybe you only want to change mount records.

You can restrict it to any set of records that you want, or you can just say change anything in the data, in the directory, any data. And if you read the man page you can get the full set of information here, but basically just think of it as find and replace for LDAP. So once you've gone through all of your hosting or IP changes, you now have a tool for doing bulk find and replace on your LDAP data.

OK, so we've talked about all the things that are new in Snow Leopard for Directory Service client, new things for the Active Directory plug-in, and new things for the Open Directory server. And how many people have been to 1 of my sessions before? OK, got a few here. You know I always like to leave you guys with either some Best Practices, some troubleshooting information, some practical information that you can take back with you, and use every day. So what we're going to do today is we're going to cover Best Practices for 4 different areas.

We're going to talk about a new way of extending the Active Directory schema that actually even uses Microsoft's own tools to do it. We're going to talk about Best Practices for setting up your Open Directory topology. So when you have an Open Directory master and replicas, what's the best way to connect them? Then we're going to talk about, because the Magic Triangle configuration is so popular, we're going to talk about some specifics for Best Practices with the Magic Triangle set up. And then finally we're going to talk about the Best Practices for how you should go about changing your IP or host name on an Open Directory server.

So we're going to start by talking about extending the Active Directory schema, and for this rather than a bunch of boring slides, I figured let's do a demo. Well it's hard to do a demo with Active Directory schema without actually using a Windows machine. Alright so, we have our Active Directory server here. Actually I'm kind of cheating, it's running in VM. But basically this is a 2008 Windows server, and you can do this with 2003 R2 using the ADAM tools, which stands for Active Directory Application Mode. In 2008 server, you have basically the same thing only Microsoft renamed it.

It's now the Active Directory Lightweight Directory Services. So this is a role that you can install on your server, it's all very fancy sounding. But basically whether you're using ADAM or the Active Directory Lightweight Directory Services, the first thing that you want to do is... first of all you're going to need an Open Directory master somewhere out there, because we need to know what the schema looks like that we're going to try and copy.

So we're not going to do a whole lot with it other than, we're basically going to just suck all of the schema from this Open Directory master. So we're just kind of going to duplicate this in Active Directory. So the tool that we use to do that is the Active Directory Schema Analyzer.

Which is a lovely UI here... and, make this a little bigger. Alright, so the first thing you want to do is you want to load the target schema, the target schema is your Open Directory master. So in this case, that's...

And we don't need to authenticate, just going to say OK. And hey presto, we have our schema.

Well that was pretty easy. Problem is, some of these attributes and classes already exist in Active Directory, so we don't want to duplicate things. So what we've got to do next is actually load what they call the base schema. So this is a schema of Active Directory as it is now.

So for that we're going to connect to Active Directory.

And for this we actually need to make a connection. By the way, anybody that is, if you're like furiously trying to scribble down notes, I actually have a white paper that I'm going to give you a link to at the end here, so you can relax.

Saw a few people going a little crazy there, so... You can see there, oh - it just pulled in a whole bunch of information. So what it's done here, and if we take a look, you can it's got a whole list of classes and attributes, and some of these came from Active Directory, some of these came from Open Directory. And so now what we want to do is, everything that's already in Active Directory, we don't want to see.

So we're going to hide those. And now if we look, now we're looking at just things that came from Open Directory; things that we might possibly need. So in the white paper, it's going to cover a whole list of different object classes and attributes that you could possibly add to the schema. Under normal circumstances, you don't need all of these.

So what we're going to do is we're just going to add 4 classes. We're going to add the computer classes, the computer lists class, the group, and the user classes, and then all the attributes that are associated with those. Because generally when you extend the schema in Active Directory, mostly what you're doing it for is you want to maybe add manage client information to a user, or to a group, or add a computer list.

So we're just going to worry about those object classes. So that's the Apple computer, Apple computer list, Apple group, and Apple user. Now of course it can't be quite this simple. If you expand these you can see oh - there's a whole lot of attributes on there. And some of these attributes actually can interfere with attributes that already exist in Active Directory schema.

So in general, what you want to do is pick out just the ones that come from the Apple schema. We're going to take out possible superior, because we're going to deal with that later. Then let's see, so basically you want to look at all the ones that have Apple in front of their name, that's kind of a good clue that it's an Apple attribute. So OK, I count flags as not, and we're going to get rid of a bunch of these. The X's by the way means that we're excluding them.

It's kind of an odd interface here. A lot of clicking. Now one attribute that we are going to keep is Mac address, even though it doesn't have Apple in front of its name. Mac address is required for computer attributes for us to recognize that it is a computer that might have managed client information attached to it. So we need to keep Mac address. And then the other one that does not have Apple in front of its name is TTL, or Time To Live.

We're going to keep that one. That one's easy, let's see. Group has a whole bunch of attributes here.

Again we're getting rid of everything except the ones that have Apple in front of them, and Time To Live. And for user we're going to get rid of again, everything that's not an Apple attribute. A lot of clicking.

All of this is detailed in the white paper, so don't worry too much about the specifics here. OK, so now we've picked all of the object classes and then the attributes that are part of the object classes, that we want to add to Active Directory So now we're ready to actually write this out as an LDAP file that we can import into Active Directory. So we're going to say create an LDAP file, let's go ahead and put it in the desktop.

Alright... so here is the LDAP file we just created, and we actually have to make a couple of little edits to it. So we're going to open it up in Notepad... and what we need to change is we need to make a couple of changes to the object classes.

And the reason we need to do that is that some of these object classes, well we don't want to create these separate, for example, Apple computer objects or Apple user objects. We want to use the user and group and computer objects that already exist in Active Directory. So we're going to piggyback on top of those objects that are already there. So instead of making a structural object class, we're going to make them auxiliary.

So to do that, we need to edit this object class category. There's 2 numbers here that are important, there is 1 which means structural, and there's 3 which means auxiliary. So Apple computer, well there's already computer objects in the directory, so we're going to make that an auxiliary class.

Now Apple computer lists... that's something that doesn't already exist in Active Directory. So that's going to be structural, so that's a 1. The other thing that we need to add for a structural class is we need to be able to say, oh we might be creating these, so we need to say what the possible superiors are for this object. So where could it possibly be created? So it could be in an OU, it could be in a CN.

So we just add that to the bottom of the list here. And fix up the formatting... OK, and then a group again, this is an auxiliary class because there's already groups in Active Directory. And user, there's already users in Active Directory, so that's also auxiliary. The last thing we need to do is we need to be able to say OK, so we said we want auxiliary classes for the user and the group and the computers, well we didn't tell Active Directory what these other objects are that we're going to piggyback on top of, because I really don't want to have to type them. I've cheated and created a little text file with this information already. And again, this is all in the white paper.

But basically we're going to add this to the bottom of the LDAP file. And we can see here is, basically we're saying the Apple user... class that we're adding, is going to match up with user class that already exists in Active Directory and so on. So Apple computer goes to computer, Apple group goes with group. OK, so now we're going to go ahead, save.

And then the last step is just actually go ahead and import this all into Active Directory itself, and to do that we actually use the LDIFDE command that exists in Active Directory. This is what you do anytime you're going to import a LDIF. So let's find our file.

So weird typing DOS commands.

OK, got a few switches to add here. Just a few. Basically what we're telling it here is that we want to pull things from this file, and if you look at the schema file itself, or the LDIF file itself, you'll see that we've kind of cheated - we've put in DC = X instead of the actual search base for the server.

So what we're saying is oh, we're going to substitute everywhere that it says DC = X is going to be actually DC = our actual search base, which in this case is WWDC.com.

Alright, and if I haven't mistyped anything... oh!

Yeah, that's... usually if you get an error, that means that there is some sort of spacing issue.

Oh, so it's a problem with where I added possible superiors here.

I think there's an extra space in there somewhere.

What was that old Apple commercial, was like people yelling out - at your config.sys and...

Well there's still a space in there somewhere then.

I highly recommend when you do this yourself, that you don't do it in front of a large audience. Unless of course that is your thing.

OK, I'm not seeing it, but...

OK we'll try it 1 more time.

Oh, failed on line 762, last token starts with D.

OK. Alright we're going to look at line 762 real quick and then we're going to move on if... It's very sensitive to little typos like this unfortunately.

No, that's correct.

Something in my copy paste, because this is the line that it's complaining about, so...

No, alright. But anyway, that was the last step in this, so basically if you type correctly you would actually get this back saying, hey it's all done, there were no errors, and you're done.

And the advantage to doing your schema updates this way, is that rather than before where you had to kind of either by hand go through the reference information for Open Directory, pull out all the OID information, try to build your own LDIF file, you actually now have a way of doing this that is basically using all Microsoft tools that you can give to your Active Directory administrator and say, here you go.

OK, so like I said, as I promised, there is a white paper for this. So seminars, say Apple.com, seminars online. Modifying an Apple. There's also documentation from Microsoft site on ADAM itself.

I'll just give you guys a couple of seconds. I see people writing furiously.

OK, so moving on. We'll talk very quickly about Open Directory topology. So with Open Directory you have a lot of different ways that you can lay out your topology. You have a master, that master can have 32 replicas, and each replica can have 32 replicas.2 So you've got a lot of different replicas to play with, and you have 3 levels of hierarchy that you can have.

And you can kind of play with this, mix and match. You use replicas, for example, to... you can have a replica close to a site for example, so that each site does not have to go out over maybe a slow link to get to the master. You might also use it for load balancing, a lot of different reasons to use replicas.

But 1 thing that trips people up is after they set these up, they sometimes run into replication issues; particularly slow replication. And the key to understanding why you see this is in understanding how Open Directory replicates. The important thing to remember is that Open Directory replication is serial.

So replication starts at the master, let's say. First it goes out to each of the replicas that are connected to the master, so it does 1 first, then the next one, and so it doesn't do all of them at once. It does each one individually. Then each of those replicas replicate serially to any replicas that it might be connected to.

So basically if you have 1 slow replica, that slows down all of the other replicas that are behind it. So they can kind of basically stack up and be waiting, and then replication can take forever to get to the last one, if there's one slow link in the middle.

So the way to get around this is to make sure that you have all of your replicas that have slow connections, at your lowest level of the hierarchy. So they should be connected to a relay rather than to the OD master itself. And also, if you have a lot of replicas connected to relays, you probably don't want to have a lot of other replicas connected to a relay if you have any slow connections in there. So maybe keep all of your slow connections on 1 particular relay.

When I talk about slow connections here also, I'm not talking about any absolute speed, I'm talking relative so slow-er than any of your other connections between your replicas. So just as an example, if you have an Open Directory that's set up here in North America, you've got a master, got a few replicas, now you're going to add a replica over in Europe. That's a slow link.

Don't connect it directly to your OD master, instead connect it to one of the other replicas making it a relay, and now the other replicas don't have to wait for this replication all the way over to Europe. OK, we're going to talk about Magic Triangle. So how many people have heard of Magic Triangle? OK, it has a few other names you know, people got a little creative with this.

So there's the Magic Triangle, there's the Golden Triangle; there's the Dual Directory because you're connected to more than 1 directory. That doesn't sound quite as interesting though, so somebody came up with the Cylinder of Destiny, and I think I've heard Pyramid of Doom, or maybe that's an Indiana Jones movie, I'm not sure which.

So lots of exciting names for it, but basically what they all mean is that you have OD clients and an OD master. The OD master is bound to itself and to Active Directory, and the clients are bound to Active Directory and the Open Directory master. And this is how we normally talk about the Magic Triangle, because usually we're talking about Active Directory.

But the Magic Triangle configuration really isn't specific to Active Directory So you could actually instead of Active Directory, you could have another Open Directory server. You could have some other third party server like say, a Sun LDAP or eDirectory, something like that. The main thing to keep in mind here with the Magic Triangle set up, is that we set it up.

The order you do things is important. So how many... so a lot of you were here in other sessions that I've done? When I talk about troubleshooting, what's the first thing I tell everybody to do? Yeah. Check your ENS. OK, this is going to save you a lot of pain down the road, so do that first.

Once you've done that, you've got forward and reverse for your server, you want to bind to Active Directory first, Kerberize any services against Active Directory, or if it's some other directory. And last you want to set up the OD master, because the OD master, when you go through the creation process, is actually going to detect that hey - you're bound to something else. It has a Kerberos KDC already and I don't need to set one up on the OD master. So you'll actually notice in server admin, in the Open Directory panel, it'll show Kerberos being stopped.

This is totally normal, this is the way you want it. Doesn't mean Kerberos isn't working, it means you are not running a KDC on the master. And another Best Practice - because you're dealing with having multiple directory servers that you're bound to, it's real easy to have duplication of user accounts or other record names. You want to try to make sure you don't have duplication, especially for your admin users.

Because of course, the first record that Directory Services finds is the one it's going to go with. And our last set of Best Practices is, I just want to give you a quick overview of what you need to do to change the IP number or host name on an OD master.

Because before this required a lot of voodoo, and you had to sort of hope you were doing the right thing, so now I'm going to give you a concrete set of steps. So the first thing you're going to do is go ahead and make a change in system preferences.

So go ahead, change you IP number, make the host name change. And then those of you that have been to my sessions before, what are you going to do before you do anything else? Yeah, check the DNS. Because it really is bad to find out you've kind of changed your host name to something you didn't intend.

So check your DNS. Once you've done that, you can run the changeip tool, to change your host name and or IP number. Then go ahead, reboot... next if you're on an OD master, your OD master's Kerberos KDC is still going to be set to your old host name. So you need to re-Kerberize your server, and you do this by running slapconfig -kerberize. This will set up a new Kerberos realm, and create Kerberos principles for all of your users.

And then finally, you can update any data in the directory using the change dirdata tool.

OK, so we're going to wrap it up now and try to get to some Q and A, but if you have some questions or you want more information, you can talk to Mark or go to our training and certification site.