Active Directory Integration, right? Right. Alright. I'm Joel Rennich, Consulting Engineer with the Apple Enterprise Consulting Services. We're doing a lot of Active Directory integration. We can come on site, do a lot of that stuff. Last year or two, this is huge. We're doing a lot of this. We're doing a lot of great stuff integrating Active Directory. OS X is really, really coming of age and being a very good corporate network citizen. That's why we're here to talk about that, to show you how we can make that better. Thank you.

A couple of things we want to talk about. What's new in Tiger? Right? You want to hear what's new in Tiger client. We want to hear what's new in Tiger server. We've got a couple of really rough kind of hand puppet ideas of different ways to kind of orchestrate this.

An hour is not nearly enough to go over all the stuff, the different ways that you can deploy this. And even I want to do some of the fun stuff that I've been doing lately, which is actually Kerberos Cross Realm, slaving Active Directory to Open Directory and kind of show you some decent ideas of where that can be involved. Hopefully by the time you're done with this, you'll learn a couple of good things. That's why you're here.

Definitely how to integrate Tiger into Active Directory. We got some killer demos. Eric Clement is here to do some demos for them. And if they don't work, we'll make them work. Eric's the guy for that. So we also want to help you out with a lot of troubleshooting. We definitely want to get you to understand more of what the Active Directory plugin does and how it works.

If you go onto the web and you read some of the sites, You go out there, you get the feeling sometimes from hearing back from people that the AD plug-in is voodoo, and it's not. The AD plug-in works in a very specific, predictable manner. We're going to show you that as we go through how it joins the different kinds of connections that it makes. This is going to help you troubleshoot.

All right? How many people have the same style, setup, configuration of an Active Directory domain? There is no such thing, all right? Every Active Directory domain is different. We've got to make sure that we interact the right way with that. So understanding how the plug-in works is really going to help you with that.

Also, as we talk about some of the deployment scenarios, how to get Active Directory and Open Directory really working well, getting the management that you want out of Open Directory, getting the management that you want out of Active Directory potentially. And also, then I talked about the Kerberos cross room at the end. So some cool stuff in there.

Alright, what's new in Tiger Client? AD plugin came out in 10.3, did some good stuff. In 10.4 we do a lot of good stuff. Some of the stuff that we got for you. Who likes group membership, right? We now can support nested AD groups. We do group membership through MemberD, makes us have a lot more flexibility with a lot more different things. We can now chase down all those users in Active Directory.

We're not limited to 16 groups anymore, so we can get all those OD and the AD groups all together, put them into that user. So MemberD is huge. Really, really helps a lot with Active Directory integration in 10.4. Directory Access got a little bit of a new look. All right, a lot more options are within Directory Access.

Most of the DSConfig AD options that you were used to doing by hand from the command line, you now have check boxes in the Directory Access interface, so you don't have to get your hands dirty on the command line if you don't want to. We automatically add the AD domain. We do a little more discovery for you. We try to make it easier to settle that up. You can map the primary user and group in there, map the GID. And we also check for dead domain controllers.

So we read in what Active Directory tells us the network really looks like, but we don't always trust it. So we definitely look and make sure that the information that we're getting out of Active Directory is actually correct. The domain controllers live at those addresses before we try to bind you into those.

DSConfigAD, still have that ability to do it from the command line. We've got static mapping support so you can map over values to specific static values. Learn more about that maybe in the heterogeneous network session later on in the week. We talk about that with the LDAP plugin.

A local admin user now can set this up. You can pass that credentials in the command line. So you don't always have to do this as root. Even better is you can actually go into Etsy authorization and there's a key for DS configuration. You can set that up to a different group and then you don't even have to have an admin user to join and you can do all the directory service configuration.

Very other cool new stuff within OS X for. Should be much better in scripts. Here's an example of a one-liner on joining Active Directory. We're going to show you that in a demo in a little bit. bit, right? Nice, easy, quick, and fun to do, right? Authentication support.

NTLMv2, right? Hey, NTLMv2. Alright, so now we can comply with your security policies on your networks. If you're forced into using NTLMv2, not forced is a bad word, but if you have to use NTLMv2, we can now support it. We're better off doing Kerberos, but we support NTLMv2 for those. Kerberos support for single sign-on of the home folder and other things like that. Alright, so very good things. Portable home directories.

Another session later on in the week about that. You can find out more information about this. But I want to let you know that portable home directories work with Active Directory users. Alright, works pretty much like you think it should. Does pretty much what you think it should. This is killer for mobile accounts on laptops. Alright, we now have the ability to do all of that.

Who's got a .local domain? All right. This used to be a real pain. Had to go down, do some command line configuration, put some resolver files in there. We now make it really easy if you're in a .local environment. And I tried to make it hard on Eric, so we're actually in a .local environment here for the demos that we're going to do. All right. All you've got to do is put it in your search domain, in your network preferences.

We automatically send all the .local resolutions to the DNS server first before we try to do it out over the network over Bonjour. All right. So that makes it much, much easier. For integrating, because let's face it, when you go to the AD domain controller and you say, hey, buddy, I don't like the .locals.

Can you change it to something else? That's not making any friends. So we need to be able to work with that. And now we do. Right in the GUI, you don't have to do anything from the command line. Couple of things that we don't do. We don't sign SMB connections and we don't do DFS. Thursby Admin Mac can do that. You can take a look at their product for that stuff that you need.

Thank you. Connecting to Active Directory. So we want to go through the Active Directory Plugin Procedure. This is where we want to instill upon you that these things aren't voodoo. All right? So this is the anti-voodoo bit of the presentation. We'll show you the different steps that we go through when we're actually joining into Active Directory. I wanted to get out and do a packet trace of all this, but they thought that might turn some people off. So instead, we got a slide here that kind of lists you through the steps.

All right? So when we're binding to Active Directory, when you go to that Directory Access Utility and you click that bind button, all right, we have to do a couple of things. First thing we do is we request some SRV records, so some service records out of DNS. We're looking for LDAP, Kpassword, Kerberos SRV records. What happens if we don't find those SRV records? We don't know where to go to bind an Active Directory. What DNS has those Active Directory records? The Active Directory DNS.

Ergo, if I'm not using the Active Directory DNS, I can't find those DNS records, I'm not going to be able to join. So that, in my experience, has usually accounted for half plus all of the problems that people have with the Active Directory plugin. So you have to use the Active Directory DNS. And again, understanding how the plugin binds, understanding the pieces that go on here, are going to help you troubleshoot, are going to help you set up your installations and the things that you want to do with the Active Directory plugin.

So after we request those records, we connect over LDAP and we get basic generic Active Directory information out of the AD controller. The system that we get back from those SRV records. Once we have that, the AD plugin goes in and configures the Edge UMIT Kerberos config file. Now we can set up a Kerberos environment. We can actually do an authenticated LDAP lookup and we can get more information out of the LDAP servers that are running on Active Directory there.

So once we've generated that config file, we go down to number four, we authenticate, and we actually go through and we request the nearest domain controller. We receive that back. Step six, we recreate an EDU MIT Kerberos file specifically for that domain controller. So we can re-authenticate, go back to that one, and then we go through, we search the domain for a computer record.

If we find a computer record, we use it. If we don't find it, well, we ask you if you want to use it. If we don't find the computer record, we'll make one for you wherever you told us to put it. All right? So that's the last step, generating a new computer record if necessary.

So, still somewhat high level, and we'll hopefully show you some of the debugging about how you can even get deeper in on this. But this is where the steps that we take as we go through. Keep this in mind when you're running into Active Directory integration problems. These are the steps. See where this is breaking. Troubleshoot from there.

Files that are involved in all of this. We've got three of them in Library Preferences Directory Service. The first one is the Active Directory plist. This actually lays out all of our Active Directory integration bits, anything that we put into the GUI and directory access. All of those pieces are in there. The next one, same place, but that's our search node config. That's our authentication path. That's that we're going to Active Directory for authentication, for passwords. Next one, the third one on there, in our contacts node config, that's that contacts tab and directory access.

Finally, the fourth file that you want to take a look at with Active Directory integration, Library Preferences EDU MIT Kerberos. That's your Kerberos config file. If that's busted, you're not authenticating. So you need to make sure that's correct. Take a look at it. We automatically generate it for you. It's best if you let us generate it, because then we can respond to changes in your network. But you can take a look at that and look for any things that jump out at you as far as troubleshooting goes.

All right. Now you know all the steps, everything you need to know. We still got a half hour, well, actually almost an hour left for this. So now we want to bring Eric Clement on stage. Eric Clement is the engineer at Apple that wrote the Active Directory plugin. If Eric can't get it to work, no one can. All right? Thanks, Joel. So now we want to do a demo.

Thank you. So who's bound to Active Directory so far? That's good. I see a lot of no hands, though. That's kind of concerning. So if you've never done this before, we have an app that we call Directory Access located in the Utilities folder. You'll launch Directory Access and you'll notice that there's an Active Directory plugin. Well, let me authenticate here.

and some other people have. But let's go through some of these options. So as Joel mentioned, we added a lot of the options to the GUI that we didn't have before in Panther. So you had DSConfigAD, kind of ran some little options. We want to make sure you had all access to that and some new ones that we didn't have in Panther. So we did some renames, you'll notice. This one we'll talk a little bit about. So first of all, by default the Active Directory plugin forces everything to your local drive. This is this primary checkbox.

Because most people, you know, if you're in a Windows environment, you've always had a local drive and a network drive that mounts on the desktop or somewhere on a Windows drive and remap files, et cetera. So we do the same thing by default. Now if you actually want to force it to a network drive so you have a true mobile network home directory, you turn off that checkbox. You have a--you have a--what's considered sort of like a roaming profile. You log in, no matter what machine you log in, it's the same home directory, same preferences, same everything. Before they used to be like a DSConfigAD, local home, disable. Now it's all in the GUI.

Also, we have the mobile account caching that was there before, but we also gave you the option, people used to kind of complain that, you know, can I turn off that warning that comes up every time I log in, a new user? So you can now turn that off.

You can also change your protocol to AFP. Say you're running extremely ZIP or maybe you want an OS X server actually hosting the user's home directory, you can remap to that OS X server now and use AFP instead of SMB. Give you a little more reliability, auto reconnects and things that our SMB can't support.

We can also change your default shell. In Tiger, terminal requires a shell. So if you log in as an AD user, launch terminal and you don't have a shell programmed, terminal won't give you a shell. Kind of a security option but you can also set that by default. Mappings, you can also use briefly, you can map UIDs. For those of you that actually have Unix environments where you've got a UID, a GID and a primary group ID, you can now map those to actual values in AD assuming that you have them.

Most people don't use that. They use the default generated data that we return. So I won't worry about that too much but, you know, those of you that need it, you can map to say I actually use UID number and I actually use primary group ID. You can do that.

Now, one thing you don't want to do, which I've seen some people do, is do that. And then they wonder why there's no unique IDs on the users. So just a little tip. You don't need these on by default unless you actually use them. And we also have a third tab, administrative.

So we added the preferred domain control was there before, but we made, you know, before I had this common delimited list, you typed in names, we figured we might as well add you a real list here and you can do plus and minus and delete things and give you a little bit of UI. And also previously, it's constantly asked, but this allows you to automatically authenticate to any domain. So one of the things that we do a little different is you can actually log into any domain without specifying a domain.

But some people actually want to limit it to a specific domain. So I have three domains in my forest and I don't want users from domain A to log in. You can check--turn this off and manually change those settings and log in as only that user or that domain. So we don't worry about all this, let's go ahead and actually bind here. So Joel mentioned the fact that you got this new change in Tiger that you can actually do .local.

So what do you need to do to make that work? That's it. If you want to be more specific, you could actually say, like in this case, I'm actually Apple.local. So I will actually send all your Apple.local queries to the DNS server and no more .local problems. So to prove that, let's actually bind. Oops, if I can type it.

One of the other things that we added, which I'm sure many are very happy about, is we automatically add AD to the authentication and contacts tab. Now this is true of the LDAP plugin as well. So we try to do this across the board. So, you know, people that used to configure the plugin like, "Well, I still can't log in." What did you add to the authentication? Or was I supposed to? So we made it a little automatic for you. You'll see here some steps going through. There's the finding domain controllers, all the various steps we talked about.

and we're bound. Click OK. You'll notice under Authentication tab, it's actually added the domains. Now one of the things we did in Tiger as well, I want to just point this out, because by default in Panther, we used to list the forest as your primary domain there. We changed that in Tiger to be a little more clear to the users because they can figure out, OK, it just lists my forest. Does that mean my people in my other domains can log in? So we'll make it all domains because it's a little more clear to everybody what that means. So now to test this, the perfect test is ID.

Wow. Few groups, not too many. But you notice we got all the groups, and that's an AD user. So now let's do the same thing from the command line. Let's go back to Active Directory. Do our authentication here. I want to point out one more thing too that I didn't mention. This is not-- some people have probably run into this before. But before you had to know what your domain-- fully qualified domain DNS was. Notice it didn't complain. So I typed in the right password. And if you watch, it actually figured out it was .local.

So let's do the same thing for the command line. So we have this neat little tool that's been around since Panther. A lot more options, a lot more information. All the same things you see in the GUI exist on the command line. We'll actually bind the computer. Now the other thing is here, you know, just like in the GUI, we don't ask you for the computer name. We actually prepopulate it for you. The command line now does the same thing. So before you had to say, you know, -a and this is computer A, B, C, D, E. Well, I don't care what the computer name is. We'll just do -domain apple user administrator.

And then We're bound. Same thing I can actually remove. I can change settings so we can say turn off all domains. Disable. Let's actually go into Directory Access. Look at that. Go to Administrative. It's disabled. I can turn it back on. Do the dash show. It's re-enabled. So all the same settings are there. You can do everything from the command line. You did notice we had one request. We actually dump out all the data if you do a dash show. Before we only showed certain things. Now we show everything. So that's a big change for us. And that's it.

Thanks Eric. He'll be back. We get to the server stuff is cool. Little more on troubleshooting. Many of you are already working in an Active Directory environment, so we know you understand a little bit about Active Directory. So hopefully we give you enough understanding about the AD plugin that everything all meshes.

All right, so where to get more information? Now that you know how it binds, now you know the steps that it goes through, well how do you know which one exactly that it's hanging on and what specific part it's hanging on? The easiest way to do this is to start a debug log going from the Directory Services. All right, so to do this you can send the USR1 flag, all right, to the Directory Service service, all right, and it's gonna start debugging to library logs, Directory Service, Directory Service, debug.log.

Now you go through, you see all the steps, you see all the calls. When you're done, you don't want that log file to overrun your system. Send it a user one flag again, we'll turn it off. For really heavy stuff, you can send it a user two flag, that puts it down to API level debugging. Because of that, it's only on for five minutes. Otherwise, we'd fill up your drive pretty quick.

So you're having issues joining, you can do a user one, you can check the debug logs. Sometimes it's a little bit like reading tea leaves your first time out and seeing kind of what's going on. But you should at least get an idea of maybe where you're hanging up.

Seeing what steps you successfully complete, so that lets you know which ones are missing, which ones you didn't be able to get to. If a user one isn't enough, throw it a user two, take a look at what other output comes out of there. User two goes to the same log file, so you look in the same place either way.

Starting over. You've bound a few times, you did it in the lab, you did it at home, you did it in one location, you go to another location and you don't know whether you're coming or going. You had a couple test domains, you set them up, you destroyed them, you did something else or something bad happened, you're not on the same network, it's spinning, it's trying to find DNS, it's trying to find some other stuff. Reset it all by going into deleting these files. These are the same files that we talked about before that set up your configuration.

So by going in and by deleting those and by restarting the Directory Service app or rebooting your machine, you're going to flush all of that out which means you're going to start over with a clean slate, an un-configured Directory Service. Now you're going to be able to go back in there, rejoin to Active Directory if you want to, set all that up, go from there. So this is how you start over. Important to know.

Got another demo. We're going to bring Eric back on here. Eric's now going to talk about actually doing the debug logs and do some little bit more about in-depth about what the plugin does. So Eric. Thanks. That was quick. So let's just kind of try something that you might run into for-- let's first not configure local correctly.

And let's actually unbind. Now I'm going to do something here that I didn't point out. So many of you complain that, how do I unbind after I lose my domain or I have no connectivity? Well, I type my name and password, it says I can't unbind, but now what do I do? Well, one of the great things we did in Tiger is you can actually force unbind after it figures out that it can't contact the domain here. Well, it doesn't seem like a good username or password, but let's say we'll force unbind anyway.

So now we're on bound. Let's go ahead and turn on debug line we mentioned. So you do kill all. It's the easiest one. So that turned on debug log. And you'll notice in the system log, there's actually a message saying debug log was turned on. So let's go find that log. It's looking at library logs, directory service debug log.

Now, you'll notice a lot of other data in here. Let me just do something. I'll do an ID admin. You'll notice a bunch of other data popping up in that log. So you'll see all the calls are going into Active Directory Services, see who's calling what, you'll see lookupd called, verify d ref ref, nothing there to worry about. All we really care about here is AD plug. So always use the filters, makes your life a lot easier to see what's going on. So let's try to bind.

I'm going to bind to, oh, I thought it was actually apple.com. And my administrator and that. Let's see. You'll notice here in the log-- You'll see the various steps that Joel talked about. And here, let's see, it tried to find no domains found, unable to find the default domain. And you'll notice the area popped up was invalid domain. Okay, well, maybe it's an apple.local. Yep, same thing. No DNS servers. Well, there's nothing obvious to point this out, but obviously we know we need Apple.local here. We'll go back, do the same thing.

Okay, now we got some stuff happening. We'll let this kind of go through and finish up, and then we'll backtrack and see what exactly happened. All right, remember when I uncleanly bound, I didn't actually remove the computer record. So it says, well, I found an existing account. Do you want to join it? We'll say, yeah.

And that's all done. So let me scroll back. So we put a lot of data in here to help you find the problem so you don't have to worry about calling us to find out why you can't bind to AD. So first of all, you'll notice the various steps that come up. We actually denote those.

You'll see, first we're looking for those DNS servers. You'll notice I found a server. I got the root DSE to find out the forest. One of the big problems back in Panther was, what's my forest? Nobody seemed to know how to find out what their forest was. Well, you don't need to worry about that anymore. We find that.

So we determine that the forest is the same as the domain. You can scroll through here. You'll see, okay, found the default domain, found servers, found a global catalog. Something's not quite here because I couldn't connect to the directory to get data, but that's okay because what I did is I generated a Kerberos record.

Then I went through and said, OK, is there any site data? So I log in as the administrator to the directory, read the same data, locate any sites, which we don't have any in this configuration. And we're still using Any. So one of the things to point out is, unlike a Windows client or some other clients, we actually use the site data.

So if you're in an AD environment where I've got multiple domain controllers spread across the country, we are going to look at the site configuration the admin put into place and say, where is the nearest domain controller? We do not use NetBIOS to find that. So if your site data isn't there, you're not going to find a local domain controller. But be sure, if it's there, we'll use it. We'll find your IP address and find the nearest one. All that's done in this next step.

See, we regenerated the Kerberos file because, you know, if this was a larger environment, we may have three or four other servers. Now we found a near one. Let's regenerate the data so that we can use the nearest domain controller. We actually close out that connection that we created. And in our case, since we only have one domain controller, we reconnect to it. But here, step three, we verified the credentials, even though we just used them.

Then we go through, we look for-- now one thing that's different in Tiger is because we do do managed client, we actually look for a computer record, not only by name, the name that you entered, but also the ethernet address. So we'll actually look, if you have schema extensions in place where they actually have a Mac address tied to a computer, we'll look for that record and join that record first. So even if I typed in computer A, but computer B was my old record with the same Mac address, it'll find computer B and bind to computer B instead.

So that's just something to be aware of. But as you see, there's a lot of detail in here. We look for it by computer address. We look for it by the name. We find something. And then we joined that account record you see here. We found the computer record.

Joining the existing record, changing the password. We'll tell you whether the password worked or not. And then we look up all the local admin groups. Lots of data. Like I said, there's lots of debug data in here to see what's going on. That's basically the majority of the problems you can solve just by looking at this log.

Thanks Eric. Cool stuff. So go to the debug logs. Take a look at what's going on there. Even in a healthy system where everything's working, you want to look at those debug logs. It'll help you understand the Active Directory plug-in and all the different pieces that are going on under the covers as this happens. All right. Enough about client. What we really care about is Tiger Server, right? Yeah, all right. That's the fun stuff. Anybody can get a client.

Authentication. Client now uses NTLMv2. Server now supports NTLMv2. In addition, we support NTLMv2 for Samba. So you can enforce password policies on your OS X servers running as Windows file servers. NTLMv2, it's a checkbox. You can see that authentication box in the bottom there in the screenshot. Checkbox for NTLMv2 and Kerberos. Uncheck it. The stuff that you don't want. NTLM, LAN manager, that kind of stuff. You can also pull it out of the password server.

Before, if you didn't want a password server to keep hashes of your LAN man passwords or whatever else, you'd have to go in and use the nest command to go in and stop it from doing that. Now inside server admin in the open directory module in server admin, you can disable those. That's the top screenshot there. Going in and turning those off there. So you can pull them out of password server and you can stop Samba from using them.

Now you can be fully compliant with your security policies that you want to enforce. Now, I'm going to show you how to do that. So we have a key tab. So we have a key tab. We do Kerberos the way it's supposed to be. We don't just pass it down to the AD controller. Samba changed that recently. So we use that. When we show you the join Kerberos options in a little while, we'll build that key tab. We'll do all of that for you. So you really do have a true single sign-on environment.

Very, very cool stuff on Tiger Server with that. Now, we have a key tab. So we have a key tab. So you really do have a true single sign-on environment. Very, very cool stuff on Tiger Server with that. Now, we have a key tab. So you really do have a true single sign-on environment. Very, very cool stuff on Tiger Server with that.

Kerberos again, this is the Join Kerberos button. This is in Server Admin in the Open Directory module. Once you've joined yourself to Active Directory, it knows you're a server, you're going to have a Join Kerberos button. Going down here, clicking on this button will then go through, configure all this stuff for you, create the key tab, enable all your services to use the key tab. Anything that can use Kerberos on the OS X server side gets a key tab from that Join Kerberos command. This is also DSConfigAD enable SSO. So you can also do this from the command line if you want. So GUI and command line options that are in here.

Really, really nice stuff here too. No need to touch the domain controller. You don't have to call up the AD admin and say, hey, what's your password? I need to go over with a floppy disk and get some key tab files from you and then carry them back over somewhere else or get them securely across the network back to you. So we do all that through the GUI here. Nice and easy. Yay! It's not cool. This gets rid of some of my work now, right? And this is what I really like because then we can hit lunch by 11. We're done for the day by 3.

Cool stuff. So move on to Tiger for this. Plus we get all the other client changes. So on OS X server, we get all the stuff that we talked about about OS X client. AD plugin is essentially the same for a lot of the joining and that kind of stuff on the server. So you can still run the debug commands like we just showed you. You can still do all of those things on the server, find out what's going wrong, fix it, get it bound, get it working. Thank you.

One last time we got Eric Clement's come up here. He's gonna show you the magic of joining server into an Active Directory environment. This is the lightest demo of the bunch because it's just one button. Alright, so Eric's there on demo two. So this is actually so easy these days. And it's not much really much to demo, because you just saw the majority of it. So let's go to Directory Access. I managed to do that once in a while. Let's quit that out. So let's unlock. We'll go down to the directory.

We'll configure this. One of the new things you'll notice-- let me hide this other window-- is we actually tell you in advance when you configure on a-- an AD on a Windows-- on a server, it says, oh, by the way, if you want to enable single sign-on, go to Join Kerberos in Open Directory. Now, I'm actually going to fix something here, because I noticed this. We joined earlier with the wrong name. I just want to make sure this is-- we don't override that. You'll notice our host name was actually OS XS.

This is important. So this isn't something you would debug normally through the debug log. But if your host name does not match for Kerberos, Kerberos is not going to work. And what's important here is not the fact that the host name was also right in DNS, it's the fact that the domain name NAD also matches the domain name of the host. Because as we know, this becomes OSX.apple.local in AD. OK, we got the same message. Click OK. Let's go to Server Admin.

Yeah, you changed it. Let me just-- there we go. This keychain is locked and you're going to come type-- So we go to Open Directory, go to Settings. It's actually going to detect the fact that we're connected to a directory system and give me the option to join Kerberos. So I click Join Kerberos. And if you read it, you'll notice we're supposed to type in our local admin and password.

Now we're joined to Kerberos. You go click on Windows, for example, look at settings. We're connected to a domain. We're a domain member. Here's the domain realm. Here's the domain we're bound to. AFP is set up for Kerberos now. In fact, you can actually go to the command line. We'll sudo to root and do K list dash K. And we even have all our Kerberos principles already in place.

Thank you. Thank you, Eric. How many times can we join Active Directory in one session and have people clap, right? I think we're up to about eight now. Everyone goes through just like it should, all right? Once I get past having switched passwords on Eric for that. My apologies.

All right, one click Kerberos integration. Nice, easy, click, go. All right, if you saw when he showed you that K-list or that KT list, you saw that we generate principles for everything in there. There's ones for X-Grid, there's ones for other stuff. All right, as we Kerberize all the rest of the services, you'll get all that in there. That'll all be pulled into the system, all right? Kerberos is good, right? Single sign-on is good. Makes things easy, makes your life easier.

What I want to talk about now is a couple of different deployment options. Once you understand how the Active Directory plugin works, once you get it working, now you want to find out how you can extend it, how you can do this a little bit better. All right, so going to your environment, getting the best of both worlds, getting the best of Active Directory, getting your users and passwords out of there, playing nice with the rest of the people that run your network.

All right, we're a good corporate citizen. We want to do the right thing, so we work with Active Directory. But you still like all the OS X stuff. Work Group Manager is a nice little app for configuring some of your MCX, doing that kind of stuff. So here's some ways that you can get both of those in the same time.

Here's an example of this. Big, huge iMac. It looks a lot bigger on the screen up there than it did on my PowerBook. Alright, so we've got an iMac G5 here. This is our client. We're going to go, there's our Windows Server. Alright, we're going to go right to Active Directory using the AD plugin. We can then use Workgroup Manager, put our users into Windows, put all the information that we want in there. Alright, works the way that you want it to. So that's extending the schema. And here we have Workgroup Manager coming up there.

One option. If you have a lot of Macs, you want to integrate them fully into Active Directory, this works. If you have just a few Macs, or if you don't like getting into going into Active Directory and being very invasive, either you're getting pushback from your IT staff about that, pushback from management, you can do what we call the magic triangle.

The magic triangle is where we take your users and your information out of Active Directory. We take your authentication out of Active Directory, but we kick in group and machine management from an Open Directory server. You get a shiny XServe, get two, you can be a replica so you don't have to worry about a single point of failure, two shiny XServes, a beige box Windows running Active Directory, we'll pull the users from AD, we'll pull the management from Open Directory. You still have the option of using Workgroup Manager, you still get all of that.

But you don't have to go and you don't have to extend the scheme on the Active Directory side. Some instructions on AFP 548 about this, there's a white paper there, explain some of the stuff that I've done with that, so you can go there and look for more information on this.

So we go back to this great big iMac, a little smaller now. And this is the idea of the magic triangle. We've got an Active Directory plug-in connection to the Windows system, to Active Directory, get our users, get our passwords, get group membership out of there if we need it. At the same time, we take an OS X. server.

Get our users there. We then take an LDAP connection, just a normal plain Jane LDAP open directory connection to an XServe. We can now use Workgroup Manager. We can manage groups of users. We can manage machine accounts and we can attach MCX to that. We're not going to be able to do direct to a user account.

If you have a user in Active Directory and you want to specify the doc settings for that user, we don't have the attributes in AD so we can't write back to that. But we can put a user into Open Directory, put them into a group, then manage that.

This is the idea of the magic triangle and how you can fit all this together. It's a great reason for you to bring an OS X server into your environment. It's a great reason to extend without actually going in and modifying the scheme on the Active Directory server. Another way, we see a lot of places doing this. Last little bit that I want to talk about is really dear to my heart. Because it really puts Open Directory where I think it should be.

We've talked a lot about how we'll be nice, we'll play with Active Directory, we'll get users from Active Directory. But what happens if you'd rather do it the other way? All right, what happens if you want Open Directory to be the top dog in this relationship? If you want the passwords to be in Open Directory, and when you go into Workgroup Manager and you disable that checkbox to disable the user, they can't log in to the PC side.

So that's Kerberos Cross Realm. It's a little harder. Windows, not as easy to connect to multiple directory services at the same time as OS X is. So here's an example of how we can do this. So we had to coin a name for it something. So I like the magic triangle as a name for the other one. So we're calling this the reverse magic triangle.

So what we do, we got essentially the same layout. We've got Open Directory and we've got Active Directory. But now we create a Kerberos Cross Realm trust between the Active Directory system and the Open Directory system. All right, and there's some information at 4ammedia.com/xrealm. All right, we'll step you through all these settings and how to do that.

All right, we take these two things, we create the Kerberos Cross Realm trust. We can then go onto the Windows machine, use the ktutil command, I believe. And then we can set up. When you go to the login window, you put your username in, and then you pick a domain. One of those domains is gonna be the Kerberos Realm in Open Directory.

All right, so you're gonna be able to select that type in your username and your password and go through. Who was at the Enterprise IT State of the Union session? All right. You remember there was a bank there. Big guy from the bank, Joe. Great guy, if he's here.

came in and talked about some of the stuff that they were doing. We're using Kerberos CrossRealm. If you've caught me on iChat lately and I'm a little sleepy when you're wide awake in the afternoon, that's because I'm in Tokyo, all right, doing this kind of stuff. So we got Kerberos CrossRealm for a lot of users over there, working great, we like it. That allows them to keep everything on the iMac, the client.

They can still get some of their legacy apps that they haven't migrated over through a remote connection, all right, using a remote desktop connection back to the Windows Terminal Services, still authenticate with their open directory username and password. So here's an example of how that works. Beige box to Windows Server using Active Directory. We've got an iMac running OS X going through Open Directory, all the normal stuff to an XServe. Now we create this Cross Realm Trust between them.

Not quite the magic triangle, and that's why I say this is the reverse magic triangle. So we've got the Cross Realm Trust between there. We then create user records in both places. Active Directory has to know the user. Sometimes we pull this out of an SAP system that might be running your HR system. Script, user creation process, we generate a user instance in both Active Directory and Open Directory. In Active Directory though we randomize the password.

Nobody knows what the password is. Randomize it. But we have to have a user principle in there. We've got a user in Open Directory. They have the real password. They have the Kerberos information, everything that we need. We tag in a little file, a little attribute on the user in Active Directory. The instructions on that URL that I gave you go through a lot of this. We tag it in there saying that this is actually a CrossRealm user. That way they can log in. They use their Open Directory password. They get a Kerberos TGT.

Then you go through. You set up all your web servers with Kerberos. You go to Solaris. You use mod SPNego. You get really wild and crazy. And now when you log in on the iMac or you log in on the Windows machine, you're using the same password. You're getting the same Kerberos credentials.

You're getting single sign-on to the resources that you need to get to. Very, very cool stuff. Reverse magic triangle. Never see that the passwords are only in Open Directory. When you go to Open Directory, Workgroup Manager, disable the user, can't log in for anything because that user's out.

Alright, we've got about 25 minutes or so. A couple places that you can get more information. A lot of the documentation, sample code and everything else. This is the WWDC URL. Those URLs that I put in for those couple of deployment examples, contact me. My email is on the slides here, [email protected]. We can help you out. We can do this for you. We can get you in touch with other resources.