Mac OS X 10.5 Leopard makes Kerberos security available for NFS. This article describes how to configure NFS exports and mounts to use Kerberos.
Without Kerberos, NFS exports and mounts use a standard form of user identification known as AUTH_SYS. In each NFS request sent to the server, the NFS client simply inserts the user's user and group IDs (UID and GID) and group list into a credential that the server uses to check access against the permissions of each directory and file in the exported filesystem. Since the user of the NFS mount is not required to authenticate when mounting, it is convenient to use, though it is also not very secure. It would be relatively easy for a rogue client or user to masquerade as another user.
An NFS filesystem that is exported and mounted with Kerberos security is much more secure. To mount and access the filesystem a user must have a valid Kerberos ticket obtained from the Kerberos KDC (Key Distribution Center), and this ticket is further validated by the server. The server must also have a valid Kerberos credential so that it can authenticate itself to the client; the security works in both directions. Furthermore, the NFS data that passes over the network between client and server can also be integrity protected to prevent unauthorized alteration or privacy protected to prevent disclosure to a malicious user on the network.
Like NFS itself, Kerberized NFS is an Internet standard. It is implemented by most operating systems and NFS vendors. Kerberized NFS can be used by mounts using NFS versions 2, 3 or 4 and over UDP or TCP connections.
Before a filesystem can be NFS-exported with Kerberos, the server must be configured with NFS service principals in its Kerberos keytab file. This can be created in an Apple Open Directory environment using the sso_util utility (type man sso_util(8) in Terminal to learn more). Generally these will be created automatically when doing an authenticated binding to the Open Directory service. In other environments the Kerberos administrator can generate keys for the nfs principals and extract the appropriate keytabs using the tools for their Kerberos implementation.
When you set up a Mac OS X NFS server that will serve clients other than Mac OS X clients, you should limit the keys to only support single DES. For more information see this article.
On the server, you can verify that the Kerberos service principals for nfs are set up correctly with the klist command:
$ sudo klist -ke | grep nfs
6 nfs/server.company.com@OD.COMPANY.COM (ArcFour with HMAC/md5)
6 nfs/server.company.com@OD.COMPANY.COM (DES cbc mode with CRC-32)
6 nfs/server.company.com@OD.COMPANY.COM (Triple DES cbc mode with HMAC/sha1)
2 nfs/LKDC:SHA1.23A473C08D62474C23E1C2BDB2259CA587D58BB4@OD.COMPANY.COM (ArcFour with HMAC/md5)
2 nfs/LKDC:SHA1.23A473C08D62474C23E1C2BDB2259CA587D58BB4@OD.COMPANY.COM (DES cbc mode with CRC-32)
2 nfs/LKDC:SHA1.23A473C08D62474C23E1C2BDB2259CA587D58BB4@OD.COMPANY.COM (Triple DES cbc mode with HMAC/sha1)
Once the Kerberos keytab is set up, the filesystem can be exported using the NFS exports file (type man exports(5) in Terminal for more information). By default, an NFS filesystem is exported with standard AUTH_SYS security. For example, the following /etc/exports entry exports a filesystem with AUTH_SYS security and provides mount access to sub-directories:
/Volumes/data -alldirs
To export this filesystem with Kerberos, you must use the "sec=" option which takes a list of security flavors, separated by colons. The list is organized in preference order. Here is the same filesystem exported with Kerberos authentication:
/Volumes/data -alldirs -sec=krb5
The server can use Kerberos to provide additional services such as data integrity protection and data privacy. The following export has a security list that allows simple Kerberos authentication (krb5) (most preferred) or alternatively, Kerberos authentication with data protection (krb5i), or Kerberos authentication with data protection and data privacy (krb5p).
/Volumes/data -alldirs -sec=krb5:krb5i:krb5p
The server will allow the client to use any of the security flavors that appear in the list.
When changing an export to use Kerberos, you may need a transition period to make sure that all the clients that mount that export are capable of using Kerberized NFS and that all users have Kerberos credentials registered with the KDC. You can continue to use standard AUTH_SYS security for those clients that still need it simply by adding "sys" to the preference list. For example:
/Volumes/data -alldirs -sec=krb5:sys
This entry exports the filesystem with Kerberos authentication preferred, but continues to allow non-Kerberized mounts. Once all the clients and users are capable of Kerberized mounts, you can remove the ":sys" from the export to make it fully secure.
Alternatively, you can selectively associate security with specific clients. For example, if just two clients are incapable of Kerberized mounts and must continue to use standard AUTH_SYS security, you can create an export specific to them:
/Volumes/data -alldirs -sec=krb5
/Volumes/data -alldirs -sec=sys client1 client2
To successfully mount a Kerberized NFS filesystem you must have a valid Kerberos credential, or in Kerberos parlance, a TGT or "Ticket Granting Ticket." If the client is successfully bound to an Open Directory server that has your Kerberos credentials set up in its KDC, then the TGT will be obtained automatically when you log in. You can use the Kerberos klist command to check whether you have a TGT:
$ klist
Kerberos 5 ticket cache: 'API:1'
Default principal: john@OD.COMPANY.COM
Valid Starting Expires Service Principal
10/20/07 12:09:44 10/20/07 22:09:44 krbtgt/OD.COMPANY.COM@OD.COMPANY.COM
renew until 10/27/07 12:09:44
Or, if you have no TGT:
$ klist
klist: No Kerberos 5 tickets in credentials cache
Alternatively, you can use the /System/Library/CoreServices/Kerberos utility to display your Kerberos tickets.
Assuming you have a Kerberos TGT, you can then do the mount normally using either the mount command, or the automounter. For example:
$ mount server:/Volumes/data /mnt
Or use the automounter:
$ ls /net/server/Volumes/data
README.txt dir1 dir2
Once the mount is complete, you may notice that in addition to your Kerberos TGT you now have a ticket that provides access to your new NFS mount:
$ klist
Kerberos 5 ticket cache: 'API:1'
Default principal: john@OD.COMPANY.COM
Valid Starting Expires Service Principal
09/20/07 12:09:44 09/20/07 22:09:44 krbtgt/OD.COMPANY.COM@OD.COMPANY.COM
renew until 09/27/07 12:09:44
09/20/07 14:13:53 09/20/07 22:09:44 nfs/server.company.com@OD.COMPANY.COM
renew until 09/27/07 12:09:44
Notice that you do not need to use any special mount options. The client will check the server's "sec=" list of security flavors associated with the export, and use the most preferred flavor that it allows.
However, there is a "sec=" mount option that can be used to mandate a specific security flavor. For example, if the server exports with "-sec=krb5:krb5i:krb5p" and you require a mount with data integrity protection, then you can select that using the "sec=" mount option:
$ mount -o sec=krb5i server:/Volumes/data /mnt
If the server doesn't support that flavor, the mount will not work. For example, if the server exports with just "-sec=krb5" then the mount will not work if you use the "sec=krb5i" option:
$ mount -o sec=krb5i server:/Volumes/data /mnt mount_nfs: can't access /Volumes/data: Authentication error
It's possible that a Kerberized mount might not work. The issue might occur for a variety of reasons: The user may not have Kerberos credentials, or the server may not have a valid keytab or be misconfigured. If for any reason a Kerberized mount does not work, the NFS mount command then attempts a mount with standard AUTH_SYS security. This mount failover will succeed only if the export on the server allows the use of AUTH_SYS, for example:
/Volumes/data -alldirs -sec=krb5:sys
Failover is per-user; it could occur even on a successful mount. You, as a user with valid Kerberos credentials, may have performed the mount and have access to it, but another user without Kerberos credentials might log into your client and attempt to access the same mount. If the export is configured to allow failover to AUTH_SYS, then that user will get AUTH_SYS access, while you continue to use the filesystem with Kerberos credentials.
A server administrator should enable the failover to AUTH_SYS only to facilitate client migration to Kerberos. Once the migration is complete, the failover should be disabled by removing the option to use AUTH_SYS.
If for some reason a Kerberized mount does not work, the mount command will most likely display "Authentication error" and nothing more. If a Kerberized automount does not work, the message may be just "Operation not permitted." These messages provide little clue as to the root cause of the issue. Fortunately, the gssd daemon, which sets up Kerberized mounts, logs more descriptive messages to the system log. For example, in /var/log/system.log:
gssd[5740]: nfs client Kerberos: server:/Volumes/data, uid=92 - Can't display user interface from this environment
This message from gssd shows that the error originated from the NFS client. A server error would display "nfs server." The issue occurred while the user with uid=92 was trying to access the filesystem mounted from server:/Volumes/data. In this case, the error message is "Can't display user interface from this environment" which is expected when a user has no Kerberos credentials. In this case, the user with uid=92 has been denied access. Kerberos authentication is performed not only at mount time, but whenever a new user attempts to access the mount, so gssd messages may also be logged if the filesystem is successfully mounted, but access is subsequently denied to some user for lack of Kerberos authentication.
Some applications may attempt to use your Kerberized NFS mount as superuser with UID=0, either directly through a setuid executable or sudo, or indirectly via a system daemon.
It is common for the superuser not to have any Kerberos credentials, which would normally prevent any access to a Kerberized mount. Since superuser proxy access is common, the NFS client makes an exception and allows superuser to use the Kerberos credential of the user that mounted the filesystem. To the server, the access will appear to be coming from the user that did the mount, not superuser.
This substitution of credentials works only if superuser is attempting to access a Kerberized filesystem that is already mounted. Unless superuser is already set up with a Kerberos credential, it cannot mount a Kerberized filesystem from scratch. This may take some adjustment since historically, mounts could done only by superuser. A regular user can do NFS mounts as long as the directory being mounted on is owned by the user.
If you are a registered Kerberos user you authenticate with a new TGT automatically when you first log in, or when you re-authenticate through screen lock. A TGT is effective only until its expiry time, though it will can be renewed up to a maximum renewable lifetime. For example a TGT displayed by the klist command shows output similar to this:
Valid Starting Expires Service Principal
09/20/07 12:09:44 09/20/07 22:09:44 krbtgt/OD.COMPANY.COM@OD.COMPANY.COM
renew until 09/27/07 12:09:44
This TGT was issued at 12:09 and is valid for 10 hours. It can be renewed for up to a week. These expiry times and limits are set up by the Kerberos administrator with the intent of making users re-authenticate periodically to limit ticket exposure without being too burdensome.
When you do a Kerberized mount, the gssd daemon uses the TGT to obtain a ticket for the mount. The klist command will display this ticket also:
09/20/07 14:13:53 09/20/07 22:09:44 nfs/server.company.com@OD.COMPANY.COM
renew until 09/27/07 12:09:44
Once the mount is complete, the session key from the Kerberos ticket is cached with the mount and remains valid as long as the server continues to accept the ticket. There is no further interaction with Kerberos on the client unless the server restarts or rejects the ticket.
If the mount requires a new ticket, NFS notifies the gssd to renew the ticket with the your current TGT. This process is completely invisible to users and applications that use the mount.
If re-authentication is needed and there is no TGT available because you have logged out, further access to the mount by long-running processes initiated by you in the background will be rejected with an EAUTH error and gssd will log messages to the system log identifying the user and the mount.
Kerberos security comes in three flavors:
A server administrator needs to choose the kind of security that the clients should use, keeping in mind that there is a performance overhead when using data integrity or privacy.
With krb5 security, the RPC header on each NFS request and reply is digitally signed. The overhead in generating and checking this digital signature is very small, so performance is not noticeably affected.
If krb5i security is used, the entire payload in every NFS request and reply is digitally signed and the signature is verified by the receiver. The overhead in computing and checking this digital signature is proportional to the size of the payload. Small metadata operations, such as listing small directories or obtaining file attributes generate small requests and replies, so performance will may not be noticeably affected. However, if you are copying large files to or from the server, the data may take almost twice as long to transfer.
The performance impact of krb5p security is even greater. Not only is the entire payload digitally signed, but the data is further processed to encrypt it before it is sent. The receiver must then decrypt the data before it can compute and check the digital signature. Again, the performance impact is proportional to the amount of data transferred. If you are copying files back and forth between client and server, it may take five times longer to transfer using krb5p.
Important: Mention of third-party websites and products is for informational purposes only and constitutes neither an endorsement nor a recommendation. Apple assumes no responsibility with regard to the selection, performance or use of information or products found at third-party websites. Apple provides this only as a convenience to our users. Apple has not tested the information found on these sites and makes no representations regarding its accuracy or reliability. There are risks inherent in the use of any information or products found on the Internet, and Apple assumes no responsibility in this regard. Please understand that a third-party site is independent from Apple and that Apple has no control over the content on that website. Please contact the vendor for additional information.