With Mac OS X Server you can configure network accounts that have user home directories hosted on the server. See the earlier post on Home Network Management Strategies as to why this is useful, and refer to Mac OS X Server User Management for specific configuration details. You have a choice of protocols you may use to share these home directories on the network, and the protocol selection has a number of consequences that may not be clear from the documentation.
Share Point Protocols
The default protocol recommendation for sharing out network home directories from Apple is AFP and it is touted as being more secure than NFS. According to the Mac OS X Server User Management documentation:
“The preferred protocol is AFP because it provides authentication-level access security. A user must log in with a valid name and password to access files. NFS file access is based not on user authentication, but on the user ID and the client IP address, so it is generally less secure than AFP. Use NFS only if you need to provide home folders for a large number of users who use UNIX workstations.”
While that is good advice in the general case, it’s not completely accurate if you have Kerberized your server and set the share point to require Kerberos authentication.
Both AFP and NFS protocols support secure authentication, and I would suggest that AFP is actually less secure because you cannot enforce data integrity and privacy (encryption) like you can out of the box with NFS.
When I first configured my server I started with AFP until I discovered that network home directories shared with AFP do not support concurrent logins with fast user switching because the first user to login owns the mount and it can’t be replaced by another login. With NFS, the the system owns the local mount point and so it doesn’t need to be replaced each login.
Kerberos Authentication
NFS with Kerberos worked well until I stumbled across what appears to be a bug in Snow Leopard. When you login, the system uses your password to authenticate with the Kerberos server and obtain a ticket that authorizes you on the network. Well, I don’t log in and out frequently except when prompted by returning from the screen saver. What I noticed was that after unlocking my workstation I was unable to sync my home folder from my mobile account and was informed that the NFS share was unavailable. After firing up Terminal and attempting to change to the mount point under /Network/Servers/myserver/Users I received “permission denied”.
As it turns out, Kerberos was doing its job. My Kerberos ticket had expired and because I didn’t go through the full login process my ticket wasn’t renewed. You can type klist from Terminal to see whether you have any valid tickets, or you can use the Ticket Viewer available from Keychain Access. You can also use the Ticket Viewer to obtain a new ticket, after which your NFS share should be accessible again.
Renew Tickets Automatically after Screen Saver
Manually renewing tickets is not really something you want to have to do, especially on a home network. This Apple Technical Support article describes a workaround to obtain a ticket granting ticket when logging in from the screen saver.
- From the Go menu choose Go to Folder
- Type /etc
- Click Go
- Open the file named "authorization" in a text editor
- Find the following text in the "system.login.screensaver” entry:
<string>The owner or any administrator can unlock the screensaver.</string>
Change it to this:<string>(Use SecurityAgent.) The owner or any administrator can unlock the screensaver.</string>
- Save the file
Renew Tickets Before Expiry
If you stay logged in for a while, you may still run into an issue where your ticket expires. This renewal is supposed to be handled for you automatically by a launch agent. To see how yours is doing, type the following at a terminal:
launchctl list com.apple.Kerberos.renew.plist
You should see a list similar to this.
launchctl list com.apple.Kerberos.renew.plist
{
"Label" = "com.apple.Kerberos.renew.plist";
"LimitLoadToSessionType" = "Aqua";
"OnDemand" = true;
"LastExitStatus" = 1;
"TimeOut" = 30;
"ProgramArguments" = (
"/usr/bin/kinit";
"-B";
);
};
If the LastExitStatus row doesn’t have a 0 next to it, then your tickets are probably failing to renew. You can work around this by modifying /System/Library/LaunchAgents/com.apple.Kerberos.renew.plist. Change the –B program argument to –R.
<key>ProgramArguments</key>
<array>
<string>/usr/bin/kinit</string>
<string>-R</string>
</array>
After making this change, restart the launch agent.
launchctl stop com.apple.Kerberos.renew.plist
launchctl start com.apple.Kerberos.renew.plist
Now the system should renew your tickets.
launchctl list com.apple.Kerberos.renew.plist
{
"Label" = "com.apple.Kerberos.renew.plist";
"LimitLoadToSessionType" = "Aqua";
"OnDemand" = true;
"LastExitStatus" = 0;
"TimeOut" = 30;
"ProgramArguments" = (
"/usr/bin/kinit";
"-R";
);
};
Conclusion
While I am glad to have found solutions, it wasn’t particularly obvious looking at the symptoms what the root cause and workarounds for these issues were. A better experience would have been:
- Documentation that more clearly stated the difference between AFP and NFS protocols as well as the authentication options available with NFS. The full Server Manager guide explains this in a bit more detail, but User Management could cover this at the high-level to make the trade offs more clear.
- Help available directly from the Server Manager dialog for share points explaining the limitations (no fast user switching, no encryption) with AFP.
- Auto-renewal of Kerberos tickets on screen saver login and before expiry without config file hacking. I find it surprising that this doesn’t just work out of the box on Mac OS.
Hi Aaron,
I came across your blog post, while trying to find a solution to my Kerberos problem – i.e. an expired Kerberos ticket is not renewed upon unlocking a screensaver.
Your instructions to modify the authorizations file worked – but I don’t understand why.
The line were you added (Use SecurityAgent.) is supposed to be just a comment, and the actual setting “rule” comes after.
Here is what my key now looks like…
[key]system.login.screensaver[/key]
[dict]
[key]class[/key]
[string]rule[/string]
[key]comment[/key]
[string](Use SecurityAgent.) The owner or any administrator can unlock the screensaver.[/string]
[key]rule[/key]
[string]authenticate-session-owner-or-admin[/string]
[/dict]
So the actual setting appears to come from “authenticate-session-owner-or-admin”, so I would have expected that to be the place to make any changes.
(if scroll further down the authorizations file you will find this key itself that actually describes the auth mechanisms it uses)
@Ninjit: I know what you mean. I picked up those steps from the Apple tech article above and unfortunately have no idea what internal voodoo makes that work.
Good article again.
Have you or anyone else tried using NFS network homes on Mountain Lion from a FreeNAS or Linux server connected to OD?
Mounting a FreeNAS NFS share seemed to work OK, but I didn’t try it with a home folder. You may want to do some basic tests first to ensure you can map user/group IDs and that NFSv4 ACLs are supported. FreeNAS NFS may not have a kerberized option, which might be important depending on your network.
Regarding network homes, I like to have access even if the server goes down, so I often create a “mobile” account on primary workstations. The downside is, there are some peculiarities with how sync is performed, so lately I’ve preferred to just create local home folders and use something like ownCloud on FreeNAS to sync data.