Thank you and welcome everyone to the Active Directory Integration session. This will be the shortest session because I think everyone is going to the airport afterwards. So let us get started. My name is Ståle Bjordal and I am with the Enterprise Professional Services Group at Apple. On the agenda, we're going to do a presentation in the beginning and followed by two live demonstrations. One that's going to talk about the server side and one that's going to be talking about the client side. If we have time, we'll do some Q&A at the end. That's pretty much how we're going to do it for about an hour or so.

First I'd like to talk a little bit about what Active Directory is and how we fit into the space that is Active Directory. Just like Open Directory, it is a directory system that's based on primarily LDAP and Kerberos. Microsoft took it, wrapped their Microsoft technologies around it, and it is proprietary, but that doesn't mean that we can't work with that.

Primarily Active Directory is used for Windows computers, make no mistake about it. Just like we want to use Open Directory to manage our clients and manage our users and groups, that's what Active Directory does in the Windows space for assigning profiles, publishing applications, setting policies for users and groups.

Their environment is slightly more complicated and complex than what we can do with Open Directory, just for the sheer size of things. Everything, just like OD, is stored in a centrally accessible database. It's organized very well. We, as Apple and OS X clients and servers, tie into Active Directory so that we can authenticate our users and authorize so we can get access to resources. We can also use Active Directory to manage our clients and groups within Active Directory or the Open Directory service and clients that are bound to the Active Directory domains.

Microsoft and AD have a little bit more of a complicated system in what we do with Open Directory. There are some terms there that's going to be somewhat of importance for us if we want to bind in in a slightly larger corporate or educational setting. Essentially you have a forest, which is the all-encompassing domain. If you have one domain, you only have one forest. Within the forest you have multiple subdomains and subdomains essentially differentiate from the domain security policies.

We as Active Directory users and OS X and clients and servers can decide if we want to bind to a specific domain or if we want to bind and allow all the users within the whole forest to authenticate and use our servers and clients. Within domains, you have a lot of different types of containers. You have OUs and you have containers and those organizational units store computer records, printers, users, groups.

It's primarily important for us to know where the computer object for the client or the server that's going to be bound, where it's going to be stored. By default, the computer object will go into a container called computers in the root of the domain, but as soon as you start expanding your Active Directory environment, you're going to have a lot of different types of containers. You have a lot of different types of containers. You have a lot of different types of containers. You have a lot of different types of containers.

You have AD administrators. More often than not, they tend to move computers around. If you come in as an Open Directory administrator and want to bind your server, you may not have access or you may not be allowed to put your OS X computer account in the default container. It's definitely something that you need to work with the Active Directory administrator on and figure out where you should put it and if you have permissions to do so.

Lastly, there's also a concept called Sites in Active Directory. It is probably the most important piece, at least I think so. Sites is a physical organization of resources based on essentially a subnet. What happens is that the AD plugin, which is the tool that's used to bind 99% of the times, will go out and it will search your Active Directory domain for sites information. If it finds a site, then it's going to attempt to use those Active Directory domain controllers first to bind with.

Sites should be used if possible. If you don't have sites configured in Active Directory domain or if you're not sure what it is, work with your Active Directory administrator and see if there's a site that is configured for your physical building or your physical location. If you don't have sites configured, what's going to happen is that the AD plugin will essentially start querying DNS and it will look for domain controllers.

It's going to try to find domain controllers that are closest to you in proximity, again based on the sites information, but if you don't have that configured, there's really no telling what domain controllers you're going to be binding to. If you are in Dallas, you would like to be bound to a domain controller in Dallas, but there are chances that you can bind to domain controllers that is literally all over the country. That could bring some problems.

So what is it that we tend to ask our customers to check out when you want to integrate with Active Directory? DNS, Fully Qualified Domain Name for your domain. This is sort of a departure from the people that are used to using NT, where your domain name was simply your NetBios name, and it could be any sort of name shorter than 15 characters.

But for Active Directory and for successful integration, Microsoft as well as Apple will recommend that your domain is a fully qualified domain name. There will be problems if your domain cannot be resolved in DNS. And when you install Active Directory, it's also going to be really hard to work around not doing what Microsoft recommends.

You will essentially be breaking your DNS and your Active Directory before you get started. Ensure that sites are configured. Again, if you don't know what it is, talk to your AD administrator. Ask him if there's a site configured for this physical location, either this building, this metro network, this WAN, whatever it may be.

Ensure that when you bind, and we're going to be demoing all of this, so in order for you to be able to bind into Active Directory, you need to have access to do so. And what we do when a binding session happens is that you're creating a computer account in Active Directory. By default, the user that can do that is any administrator that's a domain administrator or higher.

But if a company has stringent security policies, then a user that's also been delegated a right to create computer objects will suffice. So if, like we talked about earlier, if you have an Active Directory environment where your computer account is supposed to go into a specific container or an organizational unit, then all that's really needed to bind is a user that's allowed to create a computer object in the OU. for the computer object.

So what is the benefits of integrating with Active Directory? Primarily, it's because you have one username and you have one password that will get you access to all your resources on the Active Directory space, as well as the Open Directory space. You don't have to worry about users trying to use one user account when you're logging in here or one user account when you're logging in there. You don't have to worry about synchronization between Active Directory and Open Directory. It all magically works using one username and password.

You have one Kerberos domain. There's no more cross realm trust issues, although it's possible to do so, but why would you when you can integrate fully with the Active Directory Kerberos realm? It's easier for Apple as a company to maintain a presence and play in the data center, in the enterprise field. We are fully aware of how Microsoft Active Directory is very heavily used.

And, you know, you shouldn't be comparing apples and oranges, literally. But we know that if we don't play well with Active Directory and with Microsoft, then that's ultimately going to hurt us in the long run. So it benefits Apple as a company to be able to play with Microsoft and Active Directory in their environment. And using the AD plugin and binding to Active Directory does that job very, very well.

The last major benefit is once you're bound and everything is working fine, you have a transparent access to the resources. Because of the ACLs that we introduced in Tiger, you have access to resources that requires no serious maintenance other than having administrators setting the right permission or setting the right access to the resources that are available to you.

The SharePoints on the OS X Server will work with the Active Directory users and groups. The Active Directory users, whether they are logging in from an OS X client or from a Windows XP client, will have a single sign-on, fully single sign-on environment to an OS X server, to a Windows server, from an OS X client, from an XP client, and it will seamlessly work together in a single sign-on environment because of Kerberos. And that's a beautiful thing. Thank you.

So why, in addition to password and a single user sign-on, would people want to integrate? Managed client is a very good reason to do so. As you know, with Open Directory, you have the ability to bind all your OS X clients to Open Directory and then use applications such as Worker Manager to assign rights and privileges to users with regards to what printers they can access, what they can do with C++, etc.

Managed client is a very good reason to do so. As you know, with Open Directory, you have the ability to bind all your OS X clients to Open Directory, etc. Managed client is a very good reason to do so. As you know, with Open Directory, you have the ability to bind all your OS X clients to Open Directory, etc.

So what happens is that you have a client that is bound to both Active Directory and Open Directory. He will get the users from Active Directory, get the managed preferences from Open Directory. Active Directory will authenticate. It will see that it's a member of a group in Open Directory. It will see that there are some preferences that are applied to that group. And bam, your user environment has been created.

will skip through some slides here. If you don't want to use the magic triangle, what other options are there? You can do schema extensions and extend the schema in your Active Directory to accommodate essentially the Open Directory schema. What that would mean would then you could take Workgroup Manager application and then use it against Active Directory and store settings for the users and the groups straight into Active Directory without using Open Directory in the mix whatsoever.

The Service Pack 2 for Windows 2003 Server is currently scheduled to play more in the Unix, Unix, the LDAP world with an implementation of RFC 2307 that we hope is going to make it a little bit easier for us to play with that. There's also a great product called Centrify that just were announced a couple of days ago or a couple of weeks ago, which will use the familiar MMCs in Active Directory. directory to manage Macintosh clients.

Thank you, good morning, for coming here and sticking around on Friday. Can we get the demo machine up here? Great. So what we have here is a vanilla installation of Mac OS 10.4 Server. And what we're going to go through is the process of creating an Open Directory domain on the server, integrating that with Active Directory for Kerberos, and also setting up some file sharing.

So in the server admin application, the first thing we're going to do is find the Open Directory service. Excuse me. And under settings, We can actually take this to be a Open Directory master. It's going to ask you to create a DuraAdmin account. This is the account that you can use to administrate your LDAP in the Open Directory.

And we just create a secure password for that. And save. And right now in the background, it's actually going to start up a lot of services. It's going to start up a Kerberos KDC. It's going to create a Kerberos key tab file for all of your services that can be Kerberized.

It's also going to take that DIR admin account that we just created and make that the first entry in the LDAP shared domain. This runs a lot faster on our server hardware, so. Should really stress how many services it's starting in the background here, and how many plist files and configuration files. We're gonna get into that in one second, so I can show you all those.

I'm sorry. - Show us the slide and then pick a lot. - This should be done in just a second, I mean, hopefully. No, no, no. We're going to the assumption DNS is perfect right now. Okay, so we have an Open Directory master. Thank you. So if we go back to the overview, we can see that we are running. Our Kerberos is running.

So that's good. That means that we should have DNS up and going. And now we're going to go in, is we're actually going to start destroying all those nice things that we did in the background there to get this to work with Active Directory in a more clean sort of environment.

So the first thing we're going to do is we're actually going to remove the Kerberos KDC on this machine. And what we can do is use the SSO utility. And of course, we have to put in an administrative username and our secure password, which I'm going to share with everyone. So don't tell anyone after we leave here.

And if we refresh this, we can see that Kerberos has stopped. Sorry. It's at the top here. Is it kind of readable? Sort of? So now I'm going to show you some of the configuration files that were built in the background while we set up the Open Directory master.

One of which would be the edu.mit Kerberos file. And we can see here that it was auto-generated from the LDAP on the Open Directory on the local node. And here is our Kerberos Realm. But we don't want to use that Realm. We want to use our Active Directory Realm. So we're going to take this one step further. And we're going to simply get rid of it right now.

The other file that's of importance here is the Kerberos keytap file that I mentioned earlier that was created when we created an Open Directory master. We can actually read out that information by using K list minus KT. And here you can see all the service principles on the server that have been Kerberized. And what you're really looking for here is the second part of this. Well, on the left-hand side, you can see what the service is.

On the right-hand side, you can see the Kerberos realm that it's expecting to use. Now, in our case, server.copycat.org is actually our Open Directory. We want to use the Active Directory, which should just be copycat.org. So we're actually going to get rid of this file as well. It will auto-generate again when we bind into Active Directory and Kerberize the server again.

And to do that, we just do an RM again on the Etsy, KRP5, a key tab file. And that's gone. And just to make sure, we can actually ask it to read out the key tab one more time. And it comes back and says there isn't anything there.

So the next step that we want to do is we actually want to bind into the Active Directory itself. And in the Utilities folder, you'll find Directory Access. In there, we've got an Active Directory plugin. It's a great tool to use. You don't have to do LDAP mappings all over the place. You can use the LDAPv3 plugin. And when we double click on it, it's got a very informative GUI.

We know that our Active Directory domain is copycat.org and we just want to bind in a server. At the bottom here we've got lots of different options. You may choose to prefer a specific server, which we can do here. and we can allow administration by the domain admins and enterprise admins in Windows.

At this point, we want to use a Windows administrative name and password. We're told to go ahead and bind in. And it found an existing account. We had tried this out earlier to make sure everything was set up for the demo. We actually, when we unbind, will remove that. So we do clean up after ourselves.

Now it's going to tell us that we can join the Kerberos realm. And we're going to show you two different ways that you can do that. So we're going to click OK. We're going to click OK again. And the one thing that we want to double check here right now is authentication. We want to make sure that our Active Directory is moved to the top, since it is our primary authentication authority here. Click on Apply.

And what we're going to do in here again is we are going to run, we're going to show you two different ways here. In settings on Open Directory, You see there's a Curberize button down here in the bottom middle. You could use that. Alternatively, we like using the command line version of that, which is what we've shown you here right this second. So we have dsconfig-ad. which is the directory service configuration of the AD plugin and we're going to tell it to enable the SSO environment for us.

So at this point, we can go back in, tell it to look at the Kerberos key tab, and you can see it has regenerated. You can see that our Kerberos realm at the bottom, at the right side here, is copycat.org, as it should be. And this is all scriptable. You can script things to bind your machines into Active Directory, and we'll get into that more in just a little bit when we get to the client side.

I'm sorry? So the next tool we're going to show you is DSCL, which is the Directory Services Command Line Tool. And we're going to show you How easy it is to actually read out information from Active Directory. And this is actually a good test, because if you can't read out the information or reach the Active Directory, you're not going to get much further in the integration. And you can actually use this just like any other terminal window at this point. So we're going to CD into Active Directory, and get into the old domains, and we're going to move into the users.

If we do an LS on that, we can see here are the users that are in the Active Directory. We can actually read out the information on one of the users, read out Michael, and here is all the information that we can get out of the Active Directory here. I'm going to kind of scroll through this for you guys here.

So the next step we want to do is we want to show off a little bit of file sharing as well, since we have an integrated server at this point. We can start up our favorite file sharing service. and Michael Dahl. We're going to open up a second tool that we commonly use. It's Workgroup Manager. If you're not familiar with it, this is where you can actually administer your users and groups in the ADLDAP that's on your Open Directory.

And the first thing we want to do is check up here on the left hand side, you can see what directory you're looking at. In this case, we are looking at our local Open Directory master. And we're going to click the lock here. And we're going to use the diradmin username and password that we created previously when we created the Open Directory master.

So now we're authenticated to our local LDAP, and we can actually go in and make modifications. In this case, what we're going to want to do is we're going to move over to groups and create a new group, and we'll call this test group. And click on the plus sign on the right hand side. And it's going to show you the available users that you could put into that group.

In this case, we can actually go right into Active Directory and take myself and Rick and place them right into the group to apply Managed Client Settings to them. Click on Save, and now we'll go over into Preferences. This is where we can actually get into the magic triangle where we're applying group management policy onto Mac OS X clients using Active Directory.

So we're going to go into here and we're going to add in some important preferences. And it's been shown that if we modify the docs, it's always very large at all times. And on the left-hand side, you'll actually get 40% more productivity out of your end users. And we're going to make sure that it's actually there at all times to remind them of the work they should be doing. And we'll apply that.

We'll create a quick share here so that we can test that out as well. So in this case, we'll just go into the local hard drive. This could be an XServe RAID. And we'll go into Shared Items, and we'll create a new folder. WWDC test. And we will tell it to share the items in its contents.

We can go over to Users and Groups and take our Open Directory group that we just created, drag it right in as Read&Write, and save that. One other thing I want to show is we can actually see the MCX that we put in to that Open Directory group. And again, we can use DSCL. And this time we're going to tell it to look at the LDAPv3 plugin, which is going to look at our Open Directory master locally hosed on this machine.

And we're going to change directives into groups. And we can see our test group is listed right here at the bottom. And we're going to read out test group. And there's a lot of stuff here, so we're just going to do a search for left. Since we knew we moved the orientation of the dock to the left, and we can see here is the value pair right here. So that'll give you a little overview of how you can integrate with Active Directory for file services, for work group management, and for file service and work group management. Thank you guys very much. We're going to turn it over to Rick now.

Okay, well I'm going to be showing you guys today how we can integrate clients into Active Directory, what some of the options are, etc. So let me log out here. We're going to unbind the system from Active Directory. As you can see, we're all very creative with our accounts here.

Here is the Active Directory plugin just like Mike showed you. I'm going to go over some of the basic options. This is pretty much what you will see in OS X Server and OS X Clients, all the same. So obviously right here we have our Active Directory domain, copycat.org.

The computer ID I set to some dude here. You can set that to basically whatever you want. It needs to be something unique. You can use the system serial number, Mac address, something you want to talk to your Active Directory administrator about, but it just needs to be something unique.

So you can see some of the options down here. We have create mobile account at login. What that's going to do is when the user logs in with their Active Directory account for the first time to the system, it will basically take their Active Directory account information and cache it in the NetInfo database.

So let's say this is-- this is somebody's laptop. They unplug it from your guys' network and go on a trip someplace. They'll still be able to log into the system with their Active Directory account since it will keep all their information cached. Right below it you see require confirmation before creating a mobile account.

Typically I leave this turned off. The reason is when the user first logs in, it will actually prompt the user if they want to create a mobile account or not. About 70% of the time they're going to freak out and not know what it is, click no. You typically want it to be creative, so just turn off the confirmation.

Force local home directory on startup disk. You want to leave that checked if you want the user to have a local home directory. If you have that unchecked and you have this next option checked, there's a good chance the user is going to get a network home. So this next option here, use UNC path from Active Directory to derive network home location. Basically, that will hit Active Directory and look for wherever the field in Active Directory the user's network home directory is defined and mount that on their desktop.

Now, if you have that checked and the option above unchecked, the user will get a network home directory. Down here, you'll see the network protocol to be used. You can either select SMB or AFP. If you are doing network homes, it's probably best if you host them on an Apple file server and use AFP simply for the reason that some applications have issues working with SMB network home directories. And you get the benefits of AFP, like automatic reconnects if you lose your network connection temporarily, et cetera.

So down here we have the default user shell. Obviously, this is something that's not natively in Active Directory. So we set it to bash, which should be fine for most cases. But you can set it to whatever you want. So next over here we have the mappings. 95% of the time you're never going to touch this.

This would be for certain applications that, let's say, they have an issue with the automatically generated UIDs and group IDs that you get from Active Directory. If you needed to, you could set them right here in the mappings. Now some interesting options here in the administrative section. Right here you have prefer this domain server. If you want to always point the client to a very specific domain controller, you can specify that right here. Another really useful option is allow administration by.

Basically, any Active Directory groups added in here, if you have this checked, the members of those groups, if they log into your system, will have administrative rights. The only exception to that is sudo. If they're trying to use sudo, they won't be in the sudoers file and won't get administrative access there, but otherwise, they'll be able to administer the system.

So a very handy way to give a set group of people admin access to all your systems. Down here we have allow authentication from any domain in the forest. If you only want people basically authenticating in one specific domain, you would want to leave that unchecked. Otherwise, it will let anybody in any domain in Active Directory authenticate to this computer. So if you don't want that, leave this unchecked. So we're going to go ahead and bind the system back to Active Directory. So again, we put in an Active Directory user that has rights to bind the system.

Click OK. Now, the binding time here, it's going to vary depending on how your network's set up, how Active Directory is set up, et cetera. So it could take a few seconds. It could take up to a minute or two. It really kind of depends on how your network's set up. So we'll let this finish binding here.

Okay, excellent. So we are on Active Directory. So also notice on authentication, we're pointing at copycat.org here. I'm going to move that up to make the magic triangle stuff the mic setup work correctly. Okay, we're going to go ahead and quit that. Now I'm sure some of you might also be interested in binding to Active Directory from the command line, scripting this, etc. I'm going to show you guys a really basic script I wrote. There's a lot cooler things you can do if you get more into depth and you can talk to me afterwards and I can give you some of these ideas, but here's a basic example.

What this script basically does, it's going to grab the computer's serial number and it's going to use that for the computer name. So you can see right here, it's just a basic shell script, setting a variable called computer name. I'm hitting system profiler and grepping out the serial number, munging the text a bit, and that's how I get the serial number. Then right here I'm running DSConfigAD, which is the command line tool which will let you bind a system to Active Directory. You got it.

There we go. Is that better? Okay. So we can see right here we are binding to Active Directory. We're specifying a computer name, the domain, which is copycat.org, and the Active Directory user that's allowed to bind. Again, administrator in Apple is the password, so username and password's right there. So once it's bound, we're going to set some of the options in the plug-in. You can see right here, here's a couple of the example options.

I'm enabling mobile accounts, but I'm disabling the confirmation, and we are basically forcing local homes here. So next, last but not least, the system's bound to Active Directory at this point, but you still need to add the path to Active Directory to the authentication section in Directory Access so people can actually log into your system with Active Directory accounts. These two commands right here do the trick.

They're pretty widely documented on the Internet. You can find them, no problem, but that's what actually lets you authenticate once you are bound to Active Directory. So it's an example of the script. Again, there's a lot of other cool stuff you can do to really trick this out, so talk to me afterwards if you have any questions. So we won't save that. And we're going to log in with Rick, which is one of our test accounts.

Okay, so here we go. We are logged in as Rick. Notice over here, we have the dock on the left side just like Mike set up for us. So we know that we are getting managed references from Open Directory. Also wanted to show you another cool script I wrote that you guys might be able to use and please talk to me afterwards if you're interested in learning more about it.

One thing that you guys will notice is that Mac OS X isn't so good about telling you if your Active Directory password is about to expire. So we have this. I wrote a little Apple script that folds in some Perl scripts, et cetera, called Expire Check. You can set this to run as a login item for your users.

You get this. The way I have this set up is that if the password's going to expire within seven days, you'll get something like this. It says, you know, your password will expire in X amount of days. Please open system preferences. Go to accounts and change your password.

If it's going to expire in three days or less, it gets a little bit nastier. It gives you a slightly nastier message and opens up the accounts preferences for you and asks you to change your password right then and there. So again, if you're interested in how this works, come talk to me afterwards. I'd be glad to help. All right, and that's it for my client demonstration. I'll hand it back to Ståle.

Can we switch back to the presentation station please? Good demonstrations people. What we showed here was essentially a vanilla setup of integration. There's very little magic that we did when we set this up this week. The only thing that was actually custom were the login scripts that Rick showed and also the password expiration notice. Other than that, everything is out of the box. The OS X we're running 10.4.7 and the Active Directory Domain was a standard 2003 with Service Pack 1. Thank you Michael and thank you Rick.

Real quick, a little bit about troubleshooting. Unfortunately, Nicole Schock from AppleCare had a very good session about troubleshooting that started at 10:15. So if somebody has a time machine, we can go back and she will be having some good slides at her presentation about what to do, not only with Active Directory, but generally with regards to troubleshooting. But there are a couple of things that we should mention that may come in handy.

MemberD, as you guys have heard of before, is going away in Leopard. But right now, you have the capability to dump the MemberD log and the cache to see what MemberD contains. And that's pretty useful if and when you have users that, for some reason, aren't able to get to resources on an OS X server that they should be able to get to. You issue a MemberD. You have to do a D-L. It'll dump that to a log file, MemberD_Dump, inside of library logs.

Another good way of finding out what's going on is to use packet traces. It's not always for the faint of heart. And in order to narrow down the scope a little bit, you have the option of specifying some ports that you can use. Port 88, 464, 389, 32, 68 will cover LDAP, Kerberos, Global Catalog, and it will still give you every packet that goes over the wire, but at least you're not going to have TCP dump log every port and every protocol that is on the wire when you're trying to do this. That command that's listed up there will create a nice file. That will only log those files. You issue the command before you start binding, and you see what the problem is, and you kill it.

Issue the command again. It's going to create a capture out file that's going to be stored in the root of the home directory of the user that issued that command. You can either look through that file using any tool that you like. Etherpeak and Ethereal are two that people seem to be liking more than others.

Another excellent way of troubleshooting Active Directory is to use Diskl, the Director Services Command Line utility. If you can't read user records or group records or anything from Active Directory using Diskl, there's no reason for you to keep trying to authenticate users or trying to get things to move along. Because if this right here doesn't work, you're not bound correctly to Active Directory.

So what we usually do when we're on site or when you're trying to troubleshoot something, when you bind a client or a server, Try and read a record out of Active Directory. Issue an ID command to see if it's recognizing the fact that it's bound. If that doesn't work, anything you do from there on is also going to fail. So it's pretty important to make sure that you do this first.

If you are doing an Open Directory, Active Directory managed client environment, sometimes you may find that you make settings for a group or you make settings for a user that may not always take. Like Michael said, the productivity level of having a dock to the left may increase by 40%, but for some reason it doesn't take for a user. What do you do at that point? You have a couple of options. You can use this command right here that essentially tells the managed client daemon to flush the cache.

And what then happens is the next time that user logs in, it's going to go to the Open Directory and reread the record and make sure that it has the latest, greatest, and the most recent settings that's been defined for that user. If you're in NetInfo Manager, you can also do it manually in NetInfo. And if you're still using Panther, then manually doing it in NetInfo Manager is the only option you have to kill the cache like that.

Get a feel for what your DNS settings are before you start binding to Active Directory. If DNS for some reason is screwed up and you're trying to get Active Directory to work, then you're going to send yourself up for a pretty interesting day. We're not going to argue with Microsoft when they say that they recommend using Microsoft's DNS servers for Active Directory. We play very well with that. That is not to say that you can't use any other DNS server, and there are many other good ones.

But there are a couple of things that you have to keep in mind. The OS X client and the OS X server, they have to be able to get to the service records for Active Directory. And those are created automatically when you set up a DNS server for the first time when you create Active Directory.

So all you do is you just point it to the Microsoft DNS server and you're there. If you have a third-party DNS server, then you have to make sure that you point the client and the OS X server to a DNS server that contains the Active Directory service records. Because that's how the ADP works.

The ADP plugin resolves all the information it needs to, such as finding domain controllers. And then also, you want to probably use a DNS server that supports dynamic DNS. That will come in very handy. If you want to look at a debug log, a DS debug log, You kill the directory services by issuing a -usr1 command.

And what that's going to do is it's going to create a debug log that's going to essentially log everything that the directory services process does until you issue the command again. And that log file is stored in library preferences directory services. And it's a very, very good log.

Directory services is very chatty and the log file will reflect that. And in this case, when you're trying to troubleshoot something, it's actually a good thing. Open up in console, found in the utilities folder, you have a handy little window at the top right where you can actually sort by various variables, sort by AD plugin. And the only thing you'll see from then on in the log is the actual log entries that the AD plugin spits out in the directory services debug log.

Also, when you do an integration like this, keep in mind how you want to do the client management. Do you want to do a magic triangle environment? Do you want to use Open Directory for that? Do you want to do schema extensions and extend the Active Directory schema? In that case, you need to work with your AD administrators to do that and make sure that they are aware of what that means. Also, DSConfig enable SSO on the OS X Server will Kerberize the services and tell the Kerberize services what principles to use. And that's how you pretty much tell your OS X Server to use the Active Directory Kerberos Realm.