skip to primary navigationskip to content
Home

Department of Computer Science and Technology

Dr Markus Kuhn

Dr Markus Kuhn

Contents

OS X Kerberized NFS is incompatible with Active Directory

Kerberized NFS became unusable with the release of OS X Yosemite 10.10 if the Kerberos server used is Microsoft's Active Directory. The reason is that Apple only supports very outdated encryption types in its RPCSEC_GSS implementation. This was still not fixed in OS X 10.11.6 (El Capitan) as of July 2016.

The Network File System (NFS) implementation of Apple's OS X operating system does support Kerberos authentication and encryption via the RPCSEC_GSS protocol, the commonly used way to provide security for NFS, which is activated through the mount option “sec=krb5p”. Unfortunately, it became incompatible with Active Directory.

Update: The problem described on this page was fixed by Apple with the release of macOS Sierra 10.12 in September 2016. Details ...

How to reproduce the problem

You need

  • An Windows Active Directory server acting as Kerberos KDC, or any other Kerberos KDC that does not have the Triple-DES encryption type (des3-cbc-sha1) enabled (e.g. set “permitted_enctypes aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 arcfour-hmac”).
  • A user principal password registered on that Active Directory
  • A NFS service principal keytab registered on that Active Directory
  • An NFS server with suitable Kerberos configuration (/etc/krb5.keytab installed, etc.)

Then on an OS X 10.10 or 10.11 client machine obtain a ticket-granting ticket for the user principal and try to use that to mount a directory from the NFS server: 

$ kinit
[Javascript required]'s password: ...
$ mkdir -p filer
$ mount -o sec=krb5p nfs-server.example.com:/vol/userfiles filer
mount_nfs: can't mount /vol/userfiles from nfs-server.example.com
onto /Users/mgk25/filer: permission denied

This mount used to work on OS X 10.9, but only with the workaround that the configuration file /etc/krb5.conf had to contain the entry 

[libdefaults]
allow_weak_crypto = true

This workaround no longer works on OS X 10.10 and OS X 10.11.

Problem cause

The reason for this mount failure is that the RPCSEC_GSS authentication fails. The reason for that is that there are no commonly supported Kerberos encryption types between Active Directory, the Apple Kerberos code, and the Apple RPCSEC_GSS code in the OS X NFS kernel. The latter implements only a very outdated set of DES-based encryption types.

  • OS X NFS RPCSEC_GSS supports: des-cbc-crc, des-cbc-md4, des-cbc-md5, des3-cbc-sha1.
  • Windows Active Directory supports: aes256-sha1, aes128-sha1, des-cbc-crc, des-cbc-md5, arcfour-hmac-md5.

So the only encryption types supported by both Apple's RPCSEC_GSS code and Active Directory are two low-security 56-bit key single-DES ciphers: des-cbc-crc, des-cbc-md5

Single DES cryptography has long been deprecated due to its low key size, which is why it was available in MIT Kerberos and OS X (up to 10.9) only after enabling it by putting the line “allow_weak_crypto=true” into the configuration file /etc/krb5.conf.

Starting with OS X 10.10, the Kerberos implementation (kinit, etc.) provided by Apple no longer supports any single-DES encryption types. Placing “allow_weak_crypto=true” into /etc/krb5.conf no longer has any effect.

As a result, starting with OS X 10.10, the intersection of the encryption types supported by Apple's kinit, Apple's RPCSEC_GSS code, and Windows Active Directory is empty. Kerberized NFS is no longer possible in OS X Yosemite and El Capitan in organizations that use Active Directory as their Kerberos key-distribution center.

Required fix

The list of supported RPCSEC_GSS encryption types in OS X (Darwin) can be seen for example in gssd/gssd-64/gssd.c 

krb5_enctype NFS_ENCTYPES[] = {
	ENCTYPE_DES_CBC_CRC,
	ENCTYPE_DES_CBC_MD5,
	ENCTYPE_DES_CBC_MD4,
	ENCTYPE_DES3_CBC_SHA1
};

It can also be seen in the kernel, for example in xnu/xnu-2782.1.97/bsd/nfs/nfs_gss_crypto.h: 

#define NFS_GSS_0DES	0 // Not DES or uninitialized
#define NFS_GSS_1DES	1 // Single DES with DES_MAC_MD5
#define NFS_GSS_3DES	2 // Triple EDE DES KD with SHA1

The above values match what I saw with Wireshark when examining the Kerberos handshake during the mount command.

For interoperability with Windows Active Directory, the OS X RPCSEC_GSS NFS implementation should add support of at least one of the AES encryption types defined in RFC 3962: aes256-sha1, aes128-sha1.

Status

  • I first reported this problem to Apple via Apple Bug Report 21522754 on 24 June 2015. My bug report was later closed as “Duplicate of 7070322 (Open)”. (now renamed Feedback FB5815244)
  • After no sign of progress on my bug report for 12 months, I “escalated” the issue via a public Facebook post on 11 June 2016.
  • On 26 July 2016 I revisited by bug report and noticed that the previous reference “Duplicate of 7070322 (Open)” had changed to “Duplicate of 7070322 (Closed)”. Since the Apple Bug Report web site sadly does not allow me to view the bug report 7070322 of which my bug report is allegedly a duplicate, I have no further information on what the exact status of this fix is. I've not heard from Apple directly.
  • It appears that the latest macOS Sierra 10.12 beta now supports both aes256-cts-hmac-sha1-96 and aes128-cts-hmac-sha1-96 in RPCSEC_GSS!
  • If you have an older Active Directory setup, created before Windows Server 2008, make sure you upgrade its "domain functional level" to "Windows Server 2008" or newer. Otherwise, your Active Directory will still be using only RC4 and single-DES keys, and not be compatible with macOS Sierra 10.12. Afterwards, you may also have to refresh the keytab files of your NFS servers. Otherwise these keytab files might not yet have these newer AES enctypes enabled. You probably should do that regularly, as well as updating your krbtgt keytab, say once a year, just to avoid relying unnecessarily on long-term secrets.
  • 2016-09-20: macOS Sierra 10.12 released, which finally solved this problem.
  • Our NetApp DataONTAP 8 “7-mode” NFS filer then likewise turned out not to support the AES Kerberos encryption types, and the final step required in this long saga was to upgrade our filer to NetApp's new DataONTAP 9 “Cluster Mode” operating system, where kerberized NFSv3 now work fine with macOS.
  • 2019-06-05: Apple's NFSv3 implementation appears to work well, but their NFSv4.0 client in macOS Mojave 10.14.5 still has at least one serious problem: a reprodicible kernel crash when attempting to NFSv4 mount a Kerberized NFS export without a Kerberos ticket (“kdestroy ; mount -o vers=4,sec=krb5p ...”). Apple Feedback FB6119543.
  • The AES/SHA-1 based modes of operation are the most modern ones currently standardized for use by Kerberos, but they no longer represent the state of the art in modern cryptography. There are now faster alternatives available in the form of “Authenticated Encryption with Authenticated Data” (AEAD) constructs, most notably AES-GCM. There is ongoing work to incorporate AEAD modes into Kerberos and GSS-API which anyone working on such implementations may want to follow closely:

    Implementors may also want to consider known implementation pitfalls:

  • There may also be an additional bug: while gssd still advertises the availability of the des-cbc-md4 encryption type, there is actually no sign of MD4 support in the Darwin source code. With Single-DES support gone from the Kerberos libraries, it would seem prudent now to also remove any Single-DES support from gssd and the Kernel.

References

Study at Cambridge

About the University

Research at Cambridge