Good afternoon and welcome to the Bending Directory Services Tier well session. My name is Nicole Jacque and I'm an engineer with the Enterprise Support Engineering Group. And what we're going to talk about today is we're going to start out by talking about Leopard, because that's why we're all here, right? We want to hear about Leopard.

Okay, I heard, what?

Okay, thank you. And then because Leopard is not here, not here for a little while, we're going to talk also about trouble shooting Directory Services and in particular trouble shooting the active directory plug-in so that you have some of the things that you can take back with you right away, start using, information that will useful right now.

Another just little bit of administrativia here. There is a file associated with this session. If you log into the attendee site, I tried to make it a little easier for you guys this year. Instead of having to scribble down notes because there's some slides that have a lot of content on them, I've actually put most of the command line things into a notes file.

I think it's called session notes or release notes or something like that, associated with this session. So if you are on a slide and you're trying to take notes, you can not worry so much. They should, the content of most of that should be in this file for you.

So, let's start out talking about Leopard. The first we need to talk about is we made a lot of architectural changes to Directory Services in Leopard. To talk about where we're going, we have to start with where we've been. Directory Services has always been this layer in between your software and the backend plug-ins. And we've had look up D, which came to us from NeXT and it handled things like your lib system calls, it did caching and DNS. And it, it talked to the local node which was always NetInfo. That, hey I heard that.

Then for OS X, we added the Directory Services daemon. And this added the ability to talk to things like LDAP servers and Active Directory. And finally with Tiger we added member D. And we did this to get past the 16 group limit that we'd always had coming from Unix and this handled all of your group resolution and caching. So its time to make a little bit of a change here.

So for Leopard, what we've done is we've brought all three daemons into one big daemon. It's the directory service daemon and it handles everything that look up D and member D had handled before along with all of things that Directory Services had traditionally handled. And why did we do this? Well for one thing, we have one daemon.

We have less IPC dispatch. We have better performance. We save a little bit of memory by going from three processes to one. And now there's less overlap because each of the three processes handle things that other of the processes also handled and now we just have one process that does everything.

For everything that accesses Directory Services, you don't need to make any changes to your applications or anything like that. They'll call into directory services the same way they always have. But for you as administrators, as troubleshooters, you need to know that where the functionality of the things that have gone away have gone. So if you use look up D in Tiger, the main functionality as I said went into directory service. But if you used to use look up D to actually adjust some of the cache values, we have a new utility called DS cache util.

And also if you used look up D to actually look up records, things like users or mount records and so on, you can use DSCL which already exists in Tiger. For member D, the main functionality again is in directory service. But we have a new utility called DS member until that you use to do things like resolve UIDs to GUIDs or SIDs and back and forth. And finally we had our GUI utility, directory access, which has gotten a face lift. And a rename. It's now called Directory Utility. And it's gone from something that looked like this, lots of options right there on the, the first screen. Something a lot similar but simpler.

And right from the first glance, you can tell what nodes are functioning, what nodes might be disconnected and then you can always still get to the advanced settings to set everything that you used to set. Now as long as we're talking about architectural changes with Directory Services, we need to talk about the local node. Which traditionally has always been NetInfo. NetInfo has been with us for a long time. And for Leopard, there is really only one piece of information about it.

Sound effects, yes. NetInfo has kicked the bucket. It has shuffled off this mortal coil. It has rung down the curtain, joined the choir invisible. This is an X directory service.

We do need something to perform the tasks that NetInfo had been doing however. And that something is we knew DS local node.

If you start out with a fresh Leopard install, this is what you will get for your local node. If you do an upgrade install of Leopard, we will actually pull all of your data out of NetInfo, put it in a DS local node. There will be no NetInfo running. Not for local access, not for network access. NetInfo is gone.

Now with the disappearance of NetInfo, we should take a look at what's replacing it. And so DS local node is a very simple database that gets rid of a lot of the extra functionality that was left over from NetInfo being a network directory service. We didn't need all of that for a local node.

So its basically just flat file record storage. If you look inside of it, as a node as its stored in the file system, its just a series of directories, each named for the record type that its storing; you find this directory in VAR DB DS Local Nodes default.

If you were to look inside one of these directories, you would see a whole lot of files. Each of these files is an actual record. And if you look we have some built in user accounts here. They are all prefixed with an underscore. And we have the accounts that were actually set up by you on the system. And if you can't guess, they're all dot P list. So they are just P list files.

You get your standard P list header. And you can see you've got all the various record attributes that you are accustomed to seeing with in this case for example a user account. Nothing has changed about the types of data that we're storing here. It's just how we're storing it on the back end.

The good thing about this is that this is all pretty transparent to you how it's being stored on the back end and the actual data that's being stored there. So you can actually, if you think you might some sort of local node obstruction, you can just open the file and take a look.

It's also pretty handy in the case where maybe you make a change that you need to back out of, but you're already locked out of the system. Just as an example, lets say you are playing with service accls and you accidentally lock yourself out of the system altogether. Go to the single user mode, you can remove the service allc record, reboot, and you're back to normal.

Along with having NetInfo go away, we also have the various NetInfo utilities that have gone away. So for all of the NetInfo utilities that existed, which were the NI something, there is an equivalent DS something equivalent. So if you were using NICL or NI Util, you can use DSCL or DS edit group to edit your records. If you were using NI Load, you can use DS Import.

If you were using NI Dump, you can use DS Export. In the file that I associated with this session, I've actually given you an example of a script written with the NI utilities and then converted over to use a DS utilities. It's not any longer or harder. You just need to make the change. If you are using scripts that might use these utilities or you were using them for your trouble shooting.

There's also one GUI utility for NetInfo and not surprisingly that's also going away. There were really three main things that people used NetInfo manager for. And so instead of having a new replacement NetInfo manager, we've just moved that functionality into the appropriate place. So the first thing that people used NetInfo manager for was to edit the advanced settings of user and group accounts. So it made sense to move that functionality into the account pane in System Preferences. So if you right click on a user account, you have access to edit all the users that you might need access to.

Also hidden, but still there, you can right click and you can also edit groups. And one thing that you can do with this is that even though by default you may see only a list of users that you can add to a group that are on that machine, if you choose to add a user or a group, you can actually add a network user to the group and it will add them. It's just adding them to the file. You just can't browse. But we're not going to show you all of you know 5 million users you might have in your network node.

The second thing that people use NetInfo manager for was to create mount records. And so we've moved that functionality into the Directory Utility. If you go into the advanced settings, we have a tab for mounts. And you can go ahead, create you mount records as you need to.

And finally the last reason that people used NetInfo manager was to enable or disable root. So that functionality also moved into directory utility. It's just an item in the edit pull down menu. There's also a command line utility that you can use. DS Enable Root. That actually already exists in Tiger. It'll still be there in Leopard. The next thing that we want to talk about is one of our really popular directory service plug-ins. The Active Directory plug-in. How many people here use the Active Directory plug-in? Wow, forest of arms here.

I'm sorry.

What we've done with the Active Directory plug-in for Leopard is we are trying to make our Active Directory client fit in better with the Active Directory domains, whether you have large domains and forests. We're trying to scale up to those. We're also trying to make our client be able to behave like the Windows client without having to make special allowances for it, special settings in active directory to allow us to work correctly. So okay.

One of the things that we have also done is we have added domain and policy caching. So that your mobile users, how many people use mobile accounts?

Mobile users will not have to sit and query for this information. It'll be there. We'll eliminate some of the delays that you may have seen with mobile accounts.

And as I said, we're just more scale, more scalable in general. We've also added a few new configuration options. Package signing and encryption is now available.

This is actually in the Leopard bill that you got here at WWDC. So you can actually test it today, well you can test it today if you brought an Active Directory domain to, did anybody bring an Active Directory domain to test? I'm disappointed.

All right. So, DS config AD, you can enable this with package and packet encrypt options. They have three settings, allow, disable or require. So allow, the server allows it. Disable it or require it. And by default, these will be on and set to allow.

The second option that we are adding is the ability to change your computer trust account password periodically. PCs do this with a group policy. We're not going to read group policy, we actually will set an interval on the client using the pass interval option.

But now if you have requirements for example from your auditors to change your computer trust account password or you just want to be able to use the password last set value of your, your computer accounts to tell whether or not its an old computer account that's been sitting around for a while, now you'll be able to do that by setting this on the client. By default, this may not be enabled. You may have to enable it. It is currently not in the build that you have.

The last option that we've added is an option that we've added to solve a particular problem where you have a large forest and you have domains which the policies for creating those users names in the various domains, you may have ended up with overlap. So you may have a J Smith in domain one. You may have a J Smith in domain two.

And for Windows, this is no problem. Windows clients have to choose a domain name before, before they can actually log in. For Mac though, we actually look at all the various search nodes that you have configured. And so the short user name could be kind of confusing. Which J Smith are we talking about? The name space option will let you have your short user names in the format of domain name backslash user name.

And so now it will be pretty obvious when you turn this on which domain you actually should be able to see the, oh there appears to be a typo here. There should be the user name on here as well. But you will be able to tell from which domain J Smith is coming.

Finally, we have a new record type in Leopard. And the reason we have this new record type called an augmented record, is to solve the problem of we have these great new services in Leopard. How many people are excited about iCal Server and Wiki Server? I hear there was a really great session on this.

( Applause ) You want to be able to provide these services to your clients and you may be giving user accounts that are coming from some directory server that you don't have control over. Maybe it's your Active Directory server or you Sun LDAP server, some other server that you, or directory I heard a plug for that up here.

If you do not have right access to these it can be very tricky to try to implement services that want to be able to read information and write information to these user records. So a little solution that we came up with is a new server configuration option called the workgroup server configuration. So if you've installed server already, you probably have seen this screen.

What this will actually do after you choose this is it will ask you to import users. And so you'll see all the users in the node that you have configured. What are you actually doing when you import these users though is the question. Because it'll let you actually go ahead and edit these users. You don't have write access to these LDAP servers or these directory servers.

What it's actually doing is sort of tagging the record from this other directory service with the extra information that you want to be able to provide for your services and then it will return this when something queries for it. One thing to keep in mind here, is it can only add extra information. If there's information that's already coming from this other directory server, you can't replace it. It's purely an extra piece of information that you add.

So when you actually import these users, you're not creating new users records, you're creating augmented records. So these will be stored in the augment container. And the records will be stored as record type colon record name. So in the case of a user record, it would be users colon user name. It does not have to be just for user accounts, but at the moment that's the primary use for these.

Just to look a little bit closer at how this works, let's say we have an Active Directory server and we have your Leopard server. You've put a few users in your Leopard server, but you want to be able to provide services to these users coming from Active Directory. So you use workgroup mode, you use server settings, you import some of these users in the Leopard server.

So what does this look like if you actually try to query directory services? If you were to use DSCL or workgroup manager or something where you could directly query a particular search node, or a particular node in directory services, if you query the Active Directory node for a user named Nicole, it'll say here you go. Here's a Nicole user record. And in the same way if you directly query the LDAP node for a user name Steve, you would get the Steve user record.

But even though we've imported a user into the Leopard server, if you search LDAP node for a user named Nicole, its going to say there's no such user. Because there is no actual user record in the LDAP node. It's an augment record. Where the magic takes place is because for most applications, most things that use directory service, they use the search node. And the search node is smart enough that if you query for Nicole, it will say oh, there's Nicole over here, then there's some extra information about this Nicole over here and some extra information about Nicole over here. And it will actually give you both pieces of information.

There will be more information on augmented records and about other new things in Leopard in Open Directory in the Open Directory session that's Friday morning. I think it's the first session of the morning. So if you're interested in this, I highly recommend that session. But this should give you something to think about in terms of how you plan to deploy your Leopard servers for the services and the directory servers that you need to use.

Leopard's great. Leopard's got some really amazing stuff in it. But its not here yet. And we got a few months before it is. So we're going to switch tracks a little bit here. And we're going to talk about trouble shooting what you've already got in front of you which is Tiger. And this is all information that will also help you as you move forward to Leopard.

And we're going to start looking at some general directory services issues. And the way we're going to look at this is we're going to look at three of the most commonly seen configuration issues that we see with directory services. And the first one is issues with your search path.

The symptoms that you might notice is that you set up your client or your server to talk to a directory node and if you open up DSCL or you open up workgroup manager, you see all your records, things look great. Unless you happen to check the search node. But then if you actually try and do anything with these users such as add them to file permissions, look them up with the ID command, or just have them try and authenticate, doesn't work.

If you see symptoms like this, first thing to do is just check your authentication tab in directory access. Most likely its just defaulted to automatic and you need to set that. Now this is all great if you happen to be sitting right in front of your machine or you've only got one machine to deal with.

But if you got lots of clients out there and you can't actually access your server by sitting right in front of it, you've got to SSH in, it's also pretty handy to know how to get at this information from the command line. And you can use DSCL to do this. This information is in the CSP Search path of the search node. If you look at the root of the search node, in DSCL, there's an attribute called CSP Search path and it will list what you have in that authentication path.

Now because you might have lots of clients out there that maybe need a change made to them, you can also edit this information from the command line. And so you can use DSCL again to create the CSP search path value for the search policy and then append any search nodes that need to be added to that search path.

Also because order is important in terms of what order directory services looks at your various search nodes, you can reorder the order that, so this would be the equivalent of dragging them and dropping them in that authentication tab by using the change I option in DSCL. Only thing to remember here is that index zero is always your local node.

You can't change that. So you are essentially working with indexes one and beyond. All these commands are in the sample notes, so if you're furiously trying to take these down, relax a little bit.

The next issue we're going to look at is the issue of slow queries.

This can happen with any directory service node that you might have whether it's a third party LDAP service, Active Directory plug-in, particularly if you're using any custom mappings with your Active Directory server. But the symptoms that you would see are you get slowed directory service queries on your Mac clients.

And you'll also get slow log ins. And the more clients that you have doing the log ins or doing the queries, the slower it gets. And then you'll also, from the server side of things, see really high CPU utilization. And it'll spike or plateau depending on how you have your clients hitting it. But you'll definitely notice something on the server side.

The reason for this is probably because you're doing a lot of queries on attributes that are not indexed. And for every query, the directory server has to go and check every single record that it has. It's usually not real fast, especially if you have a lot of records.

So the three most important attributes that you should make sure you have indexed in whatever directory server you have are whatever you have mapped to unique ID, whatever you have mapped to primary group ID, and whatever you have mapped to map address. How many people are using the Microsoft R2 Active Directory schema? Anybody? A few.

The R2 schema adds the Mac address attribute to the schema. So whereas before it didn't even exist in the schema, so you couldn't really search on it, now its there. So if clients start querying on it and they will, you will start seeing utilization on your 80 servers because it has to visit all these records. It's a simple fix, you just need to index this inactive directory to check box in your schema manager snap in.

And the last directory service issue we're going to talk about is problems with mobile accounts. How many people use mobile accounts? One of the things that can happen when you start having problems with log ins with mobile accounts is people sort of overreact. They'll start just reimaging the machine, because that makes the problem go away. It does, it works, but there may be a simpler solution.

And so this could be mobile accounts using any node. And the symptom would be you have a user account that can't log into a particular client. But that user can log into other clients and other users can log into that client. If you have a symptom like this, before you go and blow the whole thing away, what you should is check cache account on that client. Look for the authentication authority attribute and see what it's set to.

The highlighting unfortunately is wrong on this slide. Imagine it up a line. But what can happen if you set a user to be disabled, that will get you the disabled user value in authentication authority. Or there's a problem in the process of caching the account, for security reasons, its set to disabled user to prevent some unknown bad thing from happening.

So if you look at a cache record, you see disabled user, just delete the cache record. It won't affect the home directory. The user can log in. It'll recache the record and things will be fine. It's a lot easier than reimaging the whole machine.

So finally we're going to switch over to talking very specifically about the 80 plug-in. Which is good because I saw there were an awful lot of hands in here for Active Directory. And again we're going to look at three of most common Active Directory configuration issues that we see.

And the first one relates to binding. Binding is something that if you're using the Active Directory plug-in, you've all done it, and I've actually chosen to ignore a lot of the failures that there's four steps before step five. We're not going to talk about those because for the majority of those, there was a really simple answer.

Fix your DNS.

And I did, I did a preso last year and I have these slides with bright red, I, they wouldn't make, let me make them blink or anything, but they said fix your DNS. And interestingly as time has gone on, people have fixed their DNS. And honestly, we don't see as many of those kind of problems come in anymore. So one of the remaining binding issues that we see is where the binding sort of seems to stall at step five.

When binding is having a problem, first thing to do is turn on directory service debugging. And to do that, you're going to send the USR1 signal to directory service, use the kill all command to do this. It's way less fatal than it sounds. If you wanted to have directory services, just turn on all the time, you can just create a file dot DS log at start. Put it in library preferences directory service. And then every time that directory service is restarted, it will automatically turn on directory service debugging. The logging for this goes to library logs directory service, directory service dot debug dot log.

And if you are getting that failure at step five, if you were to look at a debug log, you would see something like this. See, the AD plug-in trying to change the password for that computer account that its creating over and over again, until finally it'll come back and say that it failed. So why, why would this be happening? We need a little bit more background information here.

When it is doing this step, it's using the K password protocol to change the password. And in Tiger, K password is strictly over UDP. In Leopard, you'll be able to do it over TCP and Windows clients can use both TCP and UDP. But for Tiger, it's strictly UDP and this is part of what can lead to cases where you say, well the Windows clients can still bind.

The Windows clients are using different protocol essentially. So how do you fix this? Well, one of the first things to check is make sure that the port is open. K password over UDP uses port 464 UDP. So make sure that there's not a firewall between your client and your server. And that that port is open. This is something that often goes unnoticed because the Windows clients don't necessarily use that port.

The second thing can be that if you have an admin account that you're using to do debind to Active Directory and that user's in a lot of groups, they accumulate a lot of curb rows pack data. And that all gets put in the curb rows packet. Eventually this gets too big for UDP. And then it fails. So in that case, just use a different admin account.

Something that's in less groups. A third reason that this happens, and this actually happens fairly often is that you have a domain controller or two somewhere in your Active Directory domain or forest and it's on multiple networks. Maybe on your regular network, but it's also on maybe a private network for your SAN or a private backup network.

And those addresses are not routable to the rest of the world. So because it's UDP, we just keep sending. We don't know if the packet ever got there or not. We just keep trying and we never hear back from the server. We don't really have any way of telling if the address that we got from DNS, if there's two addresses for a server, we don't know which ones the better address.

So make sure that what you have registered in DNS for domain controller is only the IP addresses that are actually accessible to the rest of the world. So to fix that, well, the part that got grayed out here, there's a check box in the network settings for your Windows computers and this would be on your domain controllers.

There's a check box for whether or not you should register that connection in DNS. Disable that on any connections to private networks. And finally as sort of a catch all, you might just have some network setting somewhere either on your client on a switch or router somewhere that might be interfering with UDP traffic. So fix it.

Sorry. It's hard to get more specific than that. The next issue that we're going to talk about which is one that we hear about a lot which is issues with authenticating SMB clients to an OS X servers that's bound to Active Directory. So this could be an OS X server providing SMB services to windows clients, Linux clients, Mac clients, anything that wants to do SMB.

And as a symptom, any Active Directory user that tries to log in over SMB can't authenticate. But if you have users that are in for example the local node or any other directory service node of the OS X server, they can authenticate just fine to SMB. And also you're connection back to active directory appears to be working fine You can see users and everything else.

And those Active Directory users are able to authenticate to other services on the same server. They can use ASP. They can use FTP, whatever other services you might be providing. The first thing you want to check is what kinds of authentication are actually working and which kinds are not. And to do that, use the dirt tool, which stands for directory tool.

You can test two types of authentication here. Standard authentication, you just need to provide a user name and password. It'll tell you the authentication succeed or fail. You can also force it to specially test MTL authentication which is the type of authentication that SMB clients are going to use.

And for that, specify the user name and the password and to force it to do NTLM, use the dash ANT option. So if you find that standard authentication is working fine, NTLM authentication is not, you need to figure out do you fix the NTLM authentication part. And this is actually a fairly complex configuration. So I'm going to give you a little check list for what you need to check. And also by the way, I've put all this in the notes for you. ( Applause ) You're welcome.

First thing, after you bind your server, run DS config AD dash enable SSO. That's going to set up all of your services including SMB to do authentication back to Active Directory. It's going to set up the service principles for them. In the case of SMB, it's also going to edit your SMB dot com file.

Now you should probably still check this by hand anyway, especially if it's not working. And so files in FC, SMB dot com. And there's five options in there that you need to look at. The first one, make sure that your workgroup is set to the net bios name of your Active Directory domain that you're bound to. The second one, make sure that security is set to ADS, which stands for Active Directory server.

Some people will say well you could also use domain here. Don't do that. What happens if you use the domain setting, is that periodically someone will go, try to change the machine trust account password, kind of forget to tell the Active Directory plug-in about it and then all the sudden your machine account password is busted. And nothing will work on your server. So don't use domain here. Make sure you have it set to ADS.

The third option, make sure that net bios name is set to BOG, or is set to the computer account that you used when you bound to Active Directory in directory access or directory utility for Leopard. This is actually specifying the computer account that you created when you bound. If you use a different name here, its going to be looking for a different computer account that's not going to exist and that's not going to have a password for.

You want to have use spnego set to yes. This is going to enable negotiation of your authentication protocols. That's a good thing. And finally you need to have realm set to be the name of your Active Directory domain, the Kerberos domain which will match the name of your Active Directory domain. And this does need to be in all caps, Kerberos is case sensitive.

If all this checks out, the next thing to take a look at is make sure that win bind is running. Win bind in the process that directory services uses to proxy authentication back to Active Directory. If it's not running, authentication is not going to work. So you should actually have two Win bind processes running.

If you do not see these running, you can start it manually. You just need to supply the location of the Win bind configuration file to Win bind and that is currently located library preferences directory service Win bind dot com. That may change, that location may change for Leopard. That's where it is for Tiger. You'll get two processes. You only need to start one. It will start the other one for you.

If that all checks out, the last piece that you need to check is to make sure that both the Active Directory plug-in and samba are using the same password for your machine account. If these two get out of synch, it's not going to work. And since everything seems to be working except Samba, we can assume that the 80 plug-in has the right password.

So let's figure out how you can tell whether or not Samba does. So first we're going to get the machine account password from the Active Directory plug-in. To do that, look in the Active Directory P list file that's in library preferences directory service. There's a key called AD computer password.

The data field looks just like gibberish. It's actually a base 64 encoded version of the password. So use your favorite base 64 decoder to decode that. I know you all have a favorite base 64 decoder I personally happen to like using the open SSL command line tool, but use your favorite one. Also keep in mind you do need to be root to access this file.

So now that you know what the Active Directory you know what the correct password is, let's look at what samba thinks it is. To find that out, you need to look at the contents of the secrets database. And that's in VAR DB samba secret stack TDB, use the TDB dump tool to actually dump the contents of that. You will need to be root to do that. You should see a key called secrets machine password and then the name of your domain.

The data field here will actually be the plain text computer account password. So hopefully it matches what you got from AD. But if things aren't working, more than likely it doesn't. And by the way it will still look kind of like gibberish. It's just a randomly generated password.

So if they don't match, you need to reset the password that samba has for this. And to do that you're going to use the net command. Use dash F to force it and the option is change secret PW. It will prompt you for a password. Use the password, the plain text password after you base 64 decoded it that you got from the AD plug-in.

This is on, this will be all on your Tiger server.

The last AD specific problem that we're going to look at is problems where you are using Active Directory for your directory services but you're providing home directories to some of these users from an OS X server. How many people have a set up kind of like this?

A few, okay.

The configuration that we're talking about here is you have Active Directory back here. You've actually configured your user account records to point to storage that's on your OS X server. And you're providing file services to Macs, PCs, any clients that you want to use. And also important to his configuration is that you actually have the storage located on some volume that's not your boot volume. So it could be external RAID storage, it can be just a second hard drive. Could be anything. That's not on your boot volume.

And what you'll notice as symptoms is that you'll notice that clients may not be able to auto mount their home directories. Or if you go into workgroup manager, you say create home now or you use the create home dir command line tool, they don't get, the home directories don't get created on your OS X server. Or, you'll notice they get created someplace other than where you intended them to be.

Also you may notice you're virtual home shares may not work which are the special share points that are named for the user. They can connect to instead of the share points you've defined. And in the worse case, you may see that AFP log ins may just fail all together after authentications.

So the reason behind this has to do with how we translate the home directory path coming from Active Directory When you put this in Active Directory, you put in a regular Windows file path type of strain, something like backslash backslash server backslash share backslash user name. That doesn't really make a whole lot of sense to in that client, so the AD plug-in translates that into something that looks like network servers then the fully qualified name of the server and then the share and the user name. This is your typical auto mounted home directory path.

That's great. It looks like it should work. Except that in reality, if you have these home directories on a volume that's not your boot volume, the real file system path looks very similar except it has volume slash volume name in the path. So to get around this, because you can't really tell the AD plug-in whether or not a given home directory is, should go through slash volumes or not.

The way to get around this is actually to provide a link in the file system itself so that it can traverse the root and get to the share points without having to go through slash volumes. So you just create a symbolic link at the root, use the LN dash S command. And once you have this, you'll actually be able to get from network server server name share home directory without having to use the slash volumes path. And now the value that the AD plug in has calculated will be correct.

So wrapping up, things that you need to take with you about Leopard are that you've got some new utilities to replace the old ones. We've got a new local node so there'll be some things there that you may need to adjust how you trouble shot things in the past. Your script workflows that you may have existing. You may need to take a look at those, make sure that you don't need to change them, update them to use the new utilities.

You've got some new Active Directory plug-in configuration options which may affect how you plan to deploy Leopard with the AD plug-in in the future. And for providing Leopard services you'll need to think about what the best configuration is for your particular directory service set up, whether or not you use another directory server or a Leopard Open Directory server. And whether or not you should be using the standard work group or advanced type configuration. Remember that the workgroup configuration is the one that gives you the magic augmented records.

And finally for troubleshooting, make sure you check your authentication search paths, index any attributes that you know are going to get queried commonly. If you have problems with either log ins or things that just aren't working the way they should, just verify with DSCL that the information in the records is what you expect it to be. And finally if you're doing NTML authentication from an OS X server, take a look at the checklist of the various different parts of the configuration that you need to have in place and make sure that those are all correct.

For more information, we have Mark as a contact here. And as I said if you log in to the attendees site, you can find the notes that I've attached to the session. Hopefully they should be helpful to you. There's also some other notes that are about directory services like the directory services reference and stuff like that. That you may also find useful.