Open Radar

 
Summary:
This is a duplicate of radar #34617535

The TouchID preference pane is unable to load on High Sierra GM (10.13.0 17A362a) on any TouchBar MacBook Pro that is bound to ActiveDirectory and uses mobile accounts (which is a supported configuration for Active Directory for macOS High Sierra - this is mobile accounts, not portable home directories we're talking about).


Steps to Reproduce:
- Install macOS High Sierra GM on a TouchBar MacBook Pro
- Bind machine to Active Directory
- Either force, under AD bind configuration, that accounts create mobile home directories, or login with an Active Directory account and choose to make a mobile home
- Attempt to open the TouchID preference pane

Expected Results:
The TouchID preference pane should open and allow configuring TouchID on the device

Actual Results:
The TouchID preference pane is not present.

Attempts to open it manually at the location: /System/Library/PreferencePanes/TouchID.prefPane

result in a dialog with the text:

You can’t open the “Touch ID” preferences pane because it is not available to you at this time.
To see this preferences pane, you may need to connect a device to your computer.

TouchID is quite functional on the device. You can create a local user account on the same machine, not connected to AD, then log in as that account the preference pane is present and opens easily.

The root cause of this bug is a change in the logic inside the binary located at /System/Library/PreferencePanes/TouchID.prefPane/Contents/Resources/AllowPasswordPref

The AllowPasswordPref pane executable is marked by the TouchID.prefpane as the executable to run for hardware compatibility for this preference pane, via this key in the Info.plist for the TouchID.prefpane:
<key>NSPrefPaneHardwareTest</key>
<string>AllowPasswordPref</string>

The AllowPasswordPref is executed and if the return result is 0, then the OS considers the preference pane compatible and will load/display it.

On 10.12, running this executable directly on an AD bound machine with a mobile user home directory returns:
exit code: 0
log output:
2017-09-24 13:31:04.496 AllowPasswordPref[1908:31608] Hardware Check err == 0

On 10.13, the new version of this executable returns:
exit code: 254
log output:
2017-09-24 13:48:21.003 AllowPasswordPref[3202:61358] Hardware Check err == 0
2017-09-24 13:48:21.013 AllowPasswordPref[3202:61358] Is Network User? == 1

A new check has been added to the internal logic of this executable. Opening the 10.13 executable in Hopper and emitting a pseudocode disassembly, the result is:

    rbx = [[ADMUser findUserByID:getuid() searchParent:0x0] retain];
    if (((rbx != 0x0) && ([rbx hasMobileHomeDirectory] == 0x0)) && ([rbx isExternalAccount] == 0x0)) {
            rsi = 0x0;
    }
    else {
            *(int32_t *)0x100001180 = 0xfffffffe;
            rsi = 0x1;
    }

This code will _only_ ever succeed if hasMobileHomeDirectory returns 0.

By quickly using some pyobjc, I'm able to tap into the private SystemAdministration.framework myself and verify the output of that method:

>>> from Foundation import NSBundle
>>> SA = NSBundle.bundleWithPath_('/System/Library/PrivateFrameworks/SystemAdministration.framework')
>>> ADMUser = SA.classNamed_('ADMUser')
>>> user = ADMUser.currentUser()
>>> user.hasMobileHomeDirectory()
1

There is also a check in there for isExternalAccount - which looks like it's looking at the dsAttrTypeNative:external attribute on the user account.

My guess as to what logic is _attempting_ to happen here is that you're attempting to look for users that might have their home directory stored on an external thumb drive, which I can understand may not be compatible with TouchID biometric storage.

But two things:

There is absolutely NO reason that TouchID should be incompatible with mobile accounts locally stored on the device. This is very definitely a bug.

And secondly, if it's no longer compatible with accounts that are stored on external media, then that information needs to be publicly documented somewhere - and it is not.

Number of devices affected: Over 35000
Impact of bug: Reduced/delayed adoption of 10.13 until this bug is corrected.

Version:
10.13.0 17A362a

Notes: