Three Platforms, One Server Part 12: AFP Network Home Accounts
I hit another minor but infuriating snag in my plan to unify the network, though this one was all Apple. It's another case of Apple making serious changes to the way you're supposed to set your server and clients and never really trumpeting much about it. Seems everything I used to do with my server and clients is done either slightly — or in some cases radically — differently in Tiger than it was in Panther. I must admit, I never checked the manuals on this, but something as simple setting up AFP networked home accounts has become a much more complex process in Tiger than it ever was in Panther, and it took me quite a while to figure out what I had to do to make it work like it did in the Panther glory days.
Now, to remind, we don't really use AFP networked home accounts for most users. Our users' home accounts live on an NFS server — a separate machine from our authentication server — which is auto-mounted on each client at boot. The only value the authentication server stores for most users' home accounts is where those home accounts can be found on the client machines, which in our case is /home. So I haven't had to worry too much about AFP network home accounts. Until last week.
There is one exception to the above standard. Certain Macromedia products do not function properly when the user's home account is located on our NFS server, for some reason. In particular, Flash is unable to read the publishing templates, effectively disabling HTML publishing from the app. This has been a long term problem and has affected every version of Flash since we moved to our NFS home account server almost three years ago. Our solution has been to create a special user — the FlashUser — whose home account lives in an AFP network home account. When people need to work with Flash, they are encouraged to use this FlashUser account so that they can use the publishing features. This is inconvenient, but it works and we're used to it, so we keep doing it until we find a better solution. Unfortunately, when I built my master authentication server (actually, when I rebuilt it) I forgot to add the FlashUser. The teacher of the Flash class eventually came to my office and asked about the account, and I told him it should just take a minute or two to get it set up. Boy was I wrong.
The FlashUser account was always a simple AFP network user account. The user's account information and actual home account data were both stored on the same server, the data shared via an AFP share point, and configured in Workgroup Manager's "Sharing" pane as an auto-mounted home folder. According to this article guest access must be enabled on the AFP share to auto-mount. Well, that's new in 10.4, and I had no idea. And beyond that, I think it sucks. Why should guest access be enabled on a home account share point? This didn't used to be the case, and it seems way less secure to me in that by doing this you open the entire AFP home account share to unauthenticated access. Bad. Why in the hell would they change this? Not only is it less secure, but it breaks with tradition in ways that could (and in my cases did) cause serious headaches for admins setting up AFP networks home accounts.
Fortunately, after many hours of trial and error, I discovered a way to accomplish the same thing without enabling guest access on the share. It is possible, but it's quite a pain. Nevertheless, it's what I did.
Guest access can be foregone if trusted directory binding is set up between the client and the computer (which still makes no sense to me. You either have to go totally insecure, or set up an insanely secure system. Seems like we could skip the trusted binding thing if you'd just let us set up the shares sans guest access like we used to do.) Trusted binding is a bit of a pain to set up in that, as far as I know at this point, the only way to set it up is to go to every machine, log in, and run the Directory Access application. Apple really, really, really needs to give us admins some command-line tools for controlling DA. The current set is paltry at best, though I do need to look and see if there is one for setting up client-server binding (there might be, in fact it might be called dsconfigladp though this tool can not be used for setting authentication sources, for some ungodly reason, and I have yet to try it for the purposes of directory binding). But before you set up your clients, you must be sure "Enable Directory Binding" on your server is checked in the Server Admin application. By default it's not. And, at least in my case, after enabling directory binding, I had to restart my server. Fun stuff. Also, I'm fairly certain this requires a properly functioning Kerberos setup on the server, so if you're just starting out, be sure to get Kerberos running right.
Directory Access: Enable Directory Binding
(click image for larger view)
Next you need to go to your client machines one by one and bind them to the server. If you've already joined your clients to a server for authentication, you can simply navigate to the server configuration in DA, click "Edit..." to edit it, and you'll be presented with a "Bind..." button that will walk you through the process. If you haven't yet joined a client you will be asked to set up trusted directory binding when you do. From there you need to enter the hostname of the client machine, the name of a directory administrator on your server, and that user's password. In my case, I needed to also reboot the client machine. Like I said, kind of a pain.
Directory Access: Configure LDAP
(click image for larger view)
Directory Access: Edit Server Config
(click image for larger view)
Directory Access: Hit "Bind..." to Set Up Trusted Directory Binding
(click image for larger view)
But that's it. You're done. (Well, 25 computers later, that is.) I now have my FlashUser set up again, and auto-mounting its home account in the usual way (none of that "Guest Access" shit), albeit with considerably more effort than it took in Panther. This is, in my opinion, just one more reason to hate Tiger, which I generally do, as long-term readers are well aware. It's another case in which Tiger has gotten harder and more complicated to use and set up, with no apparent advantage, or at least no immediate one.
I can only hope this is going somewhere good, because from my perspective the basic things I've come to rely on in both Mac OS X Server and Client (can you say "search by name?") have gotten harder to do in Tiger. Significantly harder. And that's too bad, 'cause that's just not what I'm looking for from Apple products. If I wanted something difficult to use, I'd switch to Linux. (I'd never switch to Windows.) And if Apple software continues along its current trajectory — the Tiger trend towards a more difficult OS — and Linux software continues along its current trend towards easier software, you may see more Linux switchers than ever. Apple's draw is ease-of-use. The more they move away from that idea in the implementation of their software, the less appealing they become, to me personally, as a computing platform, and the less distinguishable they become from their competitors.
But for now, I'm sticking by my favorite computer platform. Panther was an amazing OS — it truly "just worked". It's kind of sad that Tiger has been the OS that's made start considering, however peripherally, other options. Here's hoping they do better with Leopard.
BTW, here are a couple more links of interest regarding the topic of AFP newtork home accounts in Tiger. I don't have time to read them right now, but they may prove interesting at some point.
Creating a Home Directory for a Local User at a Server
Creating a Custom Home Directory
Automatically Mounting Share Points for Clients
Setting Up an Automountable AFP Share Point for Home Directories
UPDATE:
A fellow SysAdmin and blogger, Nigel, from mind the explanatory gap (one of my systems faves) has some beefs with this article, and shares some of his own experiences which are quite contrary to what I've reported. Just to be clear, this article reflects my own experiences, and there's a bit more to my own scenario than I shared in the article, mainly because I didn't think the details were important. They may be, and I discuss it at greater length in my response to Nigel's comment. Thanks, Nigel, for keeping me on my toes on this one.
I'm not really sure what's going on here, but if I get to the bottom of it, I'll certainly report about it, either here or in a follow up post. But please read the comments for the full story, as there's really a lot missing in the article, and things start to get clearer in the comments.
Now, to remind, we don't really use AFP networked home accounts for most users. Our users' home accounts live on an NFS server — a separate machine from our authentication server — which is auto-mounted on each client at boot. The only value the authentication server stores for most users' home accounts is where those home accounts can be found on the client machines, which in our case is /home. So I haven't had to worry too much about AFP network home accounts. Until last week.
There is one exception to the above standard. Certain Macromedia products do not function properly when the user's home account is located on our NFS server, for some reason. In particular, Flash is unable to read the publishing templates, effectively disabling HTML publishing from the app. This has been a long term problem and has affected every version of Flash since we moved to our NFS home account server almost three years ago. Our solution has been to create a special user — the FlashUser — whose home account lives in an AFP network home account. When people need to work with Flash, they are encouraged to use this FlashUser account so that they can use the publishing features. This is inconvenient, but it works and we're used to it, so we keep doing it until we find a better solution. Unfortunately, when I built my master authentication server (actually, when I rebuilt it) I forgot to add the FlashUser. The teacher of the Flash class eventually came to my office and asked about the account, and I told him it should just take a minute or two to get it set up. Boy was I wrong.
The FlashUser account was always a simple AFP network user account. The user's account information and actual home account data were both stored on the same server, the data shared via an AFP share point, and configured in Workgroup Manager's "Sharing" pane as an auto-mounted home folder. According to this article guest access must be enabled on the AFP share to auto-mount. Well, that's new in 10.4, and I had no idea. And beyond that, I think it sucks. Why should guest access be enabled on a home account share point? This didn't used to be the case, and it seems way less secure to me in that by doing this you open the entire AFP home account share to unauthenticated access. Bad. Why in the hell would they change this? Not only is it less secure, but it breaks with tradition in ways that could (and in my cases did) cause serious headaches for admins setting up AFP networks home accounts.
Fortunately, after many hours of trial and error, I discovered a way to accomplish the same thing without enabling guest access on the share. It is possible, but it's quite a pain. Nevertheless, it's what I did.
Guest access can be foregone if trusted directory binding is set up between the client and the computer (which still makes no sense to me. You either have to go totally insecure, or set up an insanely secure system. Seems like we could skip the trusted binding thing if you'd just let us set up the shares sans guest access like we used to do.) Trusted binding is a bit of a pain to set up in that, as far as I know at this point, the only way to set it up is to go to every machine, log in, and run the Directory Access application. Apple really, really, really needs to give us admins some command-line tools for controlling DA. The current set is paltry at best, though I do need to look and see if there is one for setting up client-server binding (there might be, in fact it might be called dsconfigladp though this tool can not be used for setting authentication sources, for some ungodly reason, and I have yet to try it for the purposes of directory binding). But before you set up your clients, you must be sure "Enable Directory Binding" on your server is checked in the Server Admin application. By default it's not. And, at least in my case, after enabling directory binding, I had to restart my server. Fun stuff. Also, I'm fairly certain this requires a properly functioning Kerberos setup on the server, so if you're just starting out, be sure to get Kerberos running right.
Directory Access: Enable Directory Binding
(click image for larger view)
Next you need to go to your client machines one by one and bind them to the server. If you've already joined your clients to a server for authentication, you can simply navigate to the server configuration in DA, click "Edit..." to edit it, and you'll be presented with a "Bind..." button that will walk you through the process. If you haven't yet joined a client you will be asked to set up trusted directory binding when you do. From there you need to enter the hostname of the client machine, the name of a directory administrator on your server, and that user's password. In my case, I needed to also reboot the client machine. Like I said, kind of a pain.
Directory Access: Configure LDAP
(click image for larger view)
Directory Access: Edit Server Config
(click image for larger view)
Directory Access: Hit "Bind..." to Set Up Trusted Directory Binding
(click image for larger view)
But that's it. You're done. (Well, 25 computers later, that is.) I now have my FlashUser set up again, and auto-mounting its home account in the usual way (none of that "Guest Access" shit), albeit with considerably more effort than it took in Panther. This is, in my opinion, just one more reason to hate Tiger, which I generally do, as long-term readers are well aware. It's another case in which Tiger has gotten harder and more complicated to use and set up, with no apparent advantage, or at least no immediate one.
I can only hope this is going somewhere good, because from my perspective the basic things I've come to rely on in both Mac OS X Server and Client (can you say "search by name?") have gotten harder to do in Tiger. Significantly harder. And that's too bad, 'cause that's just not what I'm looking for from Apple products. If I wanted something difficult to use, I'd switch to Linux. (I'd never switch to Windows.) And if Apple software continues along its current trajectory — the Tiger trend towards a more difficult OS — and Linux software continues along its current trend towards easier software, you may see more Linux switchers than ever. Apple's draw is ease-of-use. The more they move away from that idea in the implementation of their software, the less appealing they become, to me personally, as a computing platform, and the less distinguishable they become from their competitors.
But for now, I'm sticking by my favorite computer platform. Panther was an amazing OS — it truly "just worked". It's kind of sad that Tiger has been the OS that's made start considering, however peripherally, other options. Here's hoping they do better with Leopard.
BTW, here are a couple more links of interest regarding the topic of AFP newtork home accounts in Tiger. I don't have time to read them right now, but they may prove interesting at some point.
Creating a Home Directory for a Local User at a Server
Creating a Custom Home Directory
Automatically Mounting Share Points for Clients
Setting Up an Automountable AFP Share Point for Home Directories
UPDATE:
A fellow SysAdmin and blogger, Nigel, from mind the explanatory gap (one of my systems faves) has some beefs with this article, and shares some of his own experiences which are quite contrary to what I've reported. Just to be clear, this article reflects my own experiences, and there's a bit more to my own scenario than I shared in the article, mainly because I didn't think the details were important. They may be, and I discuss it at greater length in my response to Nigel's comment. Thanks, Nigel, for keeping me on my toes on this one.
I'm not really sure what's going on here, but if I get to the bottom of it, I'll certainly report about it, either here or in a follow up post. But please read the comments for the full story, as there's really a lot missing in the article, and things start to get clearer in the comments.
Labels: Lab, MacOSX, NIX, Server, Systems, ThreePlatformsOneServer, Windows
This entry was posted
on Monday, September 25, 2006 at 1:06 AM.
You can skip to the end and leave a response.
5:06 PMok. So a couple of points here....
1. I'm sure Flash can work on NFS home directories, I think I've worked with a client where that is the setup. What are the issues you've seen?
2. Guest access does not need to be on an auto-mount share, particularly not if you have a Kerberos environment.
This suggestion was the case for 10.3 too by the way, and was more necessary then than it is now...
I don't have guest access on, and I don't use trusted directory binding for my AFP homes.
3. You do have good tools for managing DA from the command line. 'dscl' is the kind of them all, and you can use it to add search nodes, change the search path type, etc etc.
'dsconfigldap' most certainly allows you to set up binding etc.
I believe the reasoning was that Apple didn't want to replicate functionality that is in dscl in dsconfigldap, but I agree it is a little bit confusing that you use one tool to set up nodes, then another to add them to the search path. This is confusing because the GUI version gives you the checkbox to "automatically add to auth/contacts" etc, but it's not the case that you have no tools to do this from the command line.
4. Trusted directory binding doesn't actually require Kerberos I don't think, but Kerberos is worth getting working anyway.
5. You don't need to reboot clients. You can restart DirectoryService with a -HUP signal.
6. I really don't understand how you think this whole process is harder in Tiger than it was in Panther? It's certainly not the case in my experience.
The Tiger trend is towards an easier to use OS in my opinion, we now have mature tools for managing this stuff from the command line.
Tiger is much better as far as DirectoryServices goes. Much better.
12:58 AM
Hey Nigel, thanks for the lengthy comment. Let me respond to this as thoroughly as I can. Bear in mind that this has been my recent experience. What I reported in the article is, for the most part, the only way I could make AFP network home accounts work in my lab. I'm not sure why this was so, and it's entirely possible that something was wrong or set up strangely on my server. But I spent quite a while testing it, and the only way I was able to make it work was with trusted binding.
Let me go through your points one by one.
>1. I'm sure Flash can work on NFS home directories, I think I've worked with a client where that is the setup. What are the issues you've seen?
Yes, I know this is true. Flash can work on NFS home directories. It just doesn't work on ours. If the NFS export comes from a Mac OS X Server, Flash works fine. But our home account server is not Mac OS X, it's a Linux machine currently, and prior to that was a proprietary version of Linux. Why there are problems on one NFS server and not another is far beyond my understanding of the software and of file systems. But it is indeed the case for our particular scenario.
>2. Guest access does not need to be on an auto-mount share, particularly not if you have a Kerberos environment.
This may be the case. I never tested this theory, and only wrote that that's what it said in certain articles at Apple. I do find it strange, but here is a direct quote from an article entitled "Setting Up an Automountable Share Point for Home Directories" at Apple's website:
>>Set up guest access to the share point so that users with home directories on different servers can access the home directory using the ~home-directory-name/Public shortcut.
>>Click Protocols, choose Apple File Settings from the pop-up menu, and make sure "Share this item using AFP" and "Allow AFP guest access" are selected. (They are selected by default.)
>>In Server Admin, make sure AFP guest access is enabled. Connect to the home directory server and select AFP in the Computers & Services list. Click Settings, then click Access, and make sure "Enable Guest access" is selected. Also make sure the AFP service is running.
>This suggestion was the case for 10.3 too by the way, and was more necessary then than it is now...
I never had to do this in 10.3. But maybe I'm making too much a point of this. Again, it's only something I read, not what I experienced. My experience was that it only worked with trusted binding, and I assumed that was because of the guest access issue. This may be the case in my scenario, or I may just be wrong. But the Apple docs do say that, so I'm a bit confused.
>I don't have guest access on, and I don't use trusted directory binding for my AFP homes.
I honestly don't understand why it isn't working for me. I've set this sort of thing up a hundred times before. And again, the only way I could get it to work was using the method described in the article. (Actually, see below for some theories on this, and if you want, let me know what you think.)
>3. You do have good tools for managing DA from the command line. 'dscl' is the kind of them all, and you can use it to add search nodes, change the search path type, etc etc.
Yup. Use DSCL all the time. But to my knowledge you can't use it to configure parameters normally set in DA. Right?
'dsconfigldap' most certainly allows you to set up binding etc.
Good to know. That'll save me some time.
I believe the reasoning was that Apple didn't want to replicate functionality that is in dscl in dsconfigldap, but I agree it is a little bit confusing that you use one tool to set up nodes, then another to add them to the search path. This is confusing because the GUI version gives you the checkbox to "automatically add to auth/contacts" etc, but it's not the case that you have no tools to do this from the command line.
I have been able to use dsconfigldap to add an OD server config to my DA setup, but I've never been able to get it to populate the Authentication and Contacts fields. It's quite possible I'm missing something here. I'd love it if you could share the syntax for this as I really don't have a lot of time to research it right now, and it would really help me out to know.
>4. Trusted directory binding doesn't actually require Kerberos I don't think, but Kerberos is worth getting working anyway.
Wasn't sure about this. Thanks for the clarification.
>5. You don't need to reboot clients. You can restart DirectoryService with a -HUP signal.
I tried this about forty kajillion times; the only thing that worked was a reboot. Seriously, sudo killall -HUP DirectoryService. I even have a script that restarts both DirectoryService and automount, 'cause it's something I need to do quickly and easily from time to time. Forty kajillion times. No go.
>6. I really don't understand how you think this whole process is harder in Tiger than it was in Panther? It's certainly not the case in my experience.
The Tiger trend is towards an easier to use OS in my opinion, we now have mature tools for managing this stuff from the command line.
Tiger is much better as far as DirectoryServices goes. Much better.
You're quite right on the command-line front, and I'm partly just a bit overworked and frustrated. Things have gotten better command-line wise. But all I know is that in Panther setting up things like replication and AFP home accounts was much easier for me. Kerberos was a non-issue. I never got Kerberos running on my Panther servers, but that never once hung me up. AFP homes were always drop-dead simple, and I never had a problem. I've had all kinds of problems in Tiger that I never had in Panther. I guess Panther just seemed a lot more forgiving when it came to certain things.
I do have to admit, though, that I'm doing a lot more with this Tiger server than I ever did with my Panther server — hosting Linux and Windows authentication and home accounts, in addition to Macs; replication; and distributing the OD database to multiple servers, including a file server — and that this complexity could be the cause of some of my issues. For instance, I didn't mention it in the article, but I probably should have: the FlashUser's AFP home account share actually lives not on my master, but on another server whose role is set to "Connected to a Directory Server." In my mind, this shouldn't require directory binding or guest access either, but, again, this is all a true story, and this was the only way I could get this to work. I tried it every other way I know how, and it just wouldn't work without trusted binding. Do you think this could be because the share was on a server other than the Master OD server? I would love to know the answer, but I can tell you, I won't have the time to look into it for a while. I'm totally swamped.
Anyway, thanks for the comments. They're much appreciated. I kind of hurredly wrote this article, and I should have been more explicit about my setup. And perhaps a bit clearer that this has been my experience and that I'm not really quite clear what's going on (though I really thought trusted binding was a must, as that was the only way it'd work for me). It's good to know that AFP home accounts do still work without the need for trusted binding in some saner universe than mine, and I will try my best to look into what's causing mine to fail when I get a chance as it's got me a bit concerned. Until then, I'm updating the article with a notice to check the comments for some clarification.
BTW, been meaning to write and say, love the new blog. It looks great.
-systemsboy
2:28 AM
I have been able to use dsconfigldap to add an OD server config to my DA setup, but I've never been able to get it to populate the Authentication and Contacts fields. It's quite possible I'm missing something here. I'd love it if you could share the syntax for this as I really don't have a lot of time to research it right now, and it would really help me out to know.
I'll just post about this now, as it's by no means obvious :) don't feel bad about not picking it up.
doh. no 'code' or 'pre' tags allowed...
-------
nigelkersten@zombie: ~ $ dscl localhost
> cd /Search
/Search > read
CSPSearchPath: /NetInfo/DefaultLocalNode /LDAPv3/my.od.domain
NSPSearchPath: /NetInfo/DefaultLocalNode
SearchPolicy: CSPSearchPath
SearchPath: /NetInfo/DefaultLocalNode /LDAPv3/my.od.domain
ReadOnlyNode: ReadOnly
DHCPLDAPDefault: off
LSPSearchPath: /NetInfo/DefaultLocalNode
-------
So the key is that the lookup order of DirectoryService nodes, as well as the change from "Automatic" to "Search Path" or whatever Directory Access calls it are all things that are stored as attributes of the /Search node.
If you play around with switching things around inside Directory Access.app and watching these changes, you'll see how you'd go about appending and/or editing these attributes.
Thanks for the kind words about the new blog. I'm a bit of a retro-scifi nut... :)
2:29 AM
Oh and the same thing goes for the Contacts node.
----------
> cd Contact
/Contact > read
CSPSearchPath: /NetInfo/DefaultLocalNode /LDAPv3/my.od.domain
NSPSearchPath: /NetInfo/DefaultLocalNode
SearchPolicy: CSPSearchPath
SearchPath: /NetInfo/DefaultLocalNode /LDAPv3/my.od.domain
ReadOnlyNode: ReadOnly
DHCPLDAPDefault: off
LSPSearchPath: /NetInfo/DefaultLocalNode
------------
12:26 PM
Ah! Thank you. Now I see: you use dsconfigldap to add a node, and dscl to edit node values. Actually, that does kind of make sense.
Thanks for the clues. I think I can take it from there. This should help me out a lot.
Oh, and retro sci-fi? Really? I hadn't noticed. ;)
-systemsboy
8:59 PM
Hello,
Forgive me if this is a dumb question but do you have a good method for binding linux PCs to Open Directory?
My best attempts seem to either do nothing or kill the system (well it loops round during boot, failing to connect to ldap server at IP address.
Any help much appreciated.
11:03 PM
We've mainly used Fedora Core to bind to our Mac server. It's really easy. Just fill in the proper values in "authconfig" and you're good to go. We were anyway.
Beyond that, my understanding is you need to install certain libraries and configure certain files. But if you've done that and it's killing your machines, I'm at a complete loss. Sorry.
-systemsboy
4:04 AM
Okay,
I'll give Fedora a go.
I've been trying to get it done with Ubuntu but I'm getting the feeling that it's maybe less corporate and therefore domain friendly.
Thanks for the swift response.
5:12 PM
I've run across a couple of instances of a similar problem you've seen with Flash being unable to publish, and wonder if there was any other workaround/solution to creating another user account specifically for workin in Flash.
My problems are all affecting network users with home directories on a Tiger server. They're AFP tho, and not NFS. When publishing from Flash, it crashes if the user is a network account and not a local account. I haven't been able to find any other mention of this on the web, except your mention here, so I wonder how widespread the issue is, and if there's something in my setup that's specifically problematic. However, my setup is pretty standard, based on Apple's guidelines for the most part.
Has there been any mention of a fix for this?
6:31 PM
The only alternative solution for me was to re-share the NFS share as an AFP re-share from the Mac Server. But I don't remember if this worked. For the record, I have not had any problems when using network home accounts from an Mac-Server-shared location, AFP or otherwise. This is a longstanding problem that is, to some extent, specific to our network and its hardware. It's really on Adobe to fix it, but it's so low on the radar I doubt it will ever be intentionally fixed. I'll probably test it again when we get Flash 9. I'll post back when that happens if there's any relief.
-systemsboy
» Post a Comment