LAPS not working for macOS Big Sur?

[jelockwood]

I am now testing all my setup - especially Jamf related issues with macOS Big Sur and this includes the LAPS scripts provided here.

The existing setup works fine under macOS Catalina.

However it looks like there is a problem in macOS Big Sur. I am including the messages shown in Terminal but will continue to test and investigate further myself.

In addition to the error messages, the script asks for a password during execution which did not use to occur. Interestingly despite all this, it does appear to have succeeded in that the initial default password has been successfully changed and recorded in Jamf. (Tested by unlocking System Preferences with the new random password.)

Running script LAPS...
Password: 
Script exit code: 1
Script result: (23) Failed writing body
No Password is stored in LAPS, setting LAPS to initial value.
<?xml version="1.0" encoding="UTF-8"?><computer><id>147</id></computer>(23) Failed writing body
localadmin is a local user on the Computer
/Library/Application Support/JAMF/tmp/LAPS: line 179: recon: command not found
No Password is stored in LAPS.
<dscl_cmd> DS Error: -14090 (eDSAuthFailed)
Error: Password stored in LAPS is not valid for localadmin.
Current password not available, proceeding with forced update.
Reset password for localadmin
New password for localadmin is verified.
<?xml version="1.0" encoding="UTF-8"?><computer><id>147</id></computer>(23) Failed writing body
<dscl_cmd> DS Error: -14090 (eDSAuthFailed)
Error: LAPS password for localadmin is not correct!

Error running script: return code was 1.

[jelockwood]

As additional information I mentioned in my first comment above that appeared despite the error messages it had actually succeeded. However something strange seems to have happened.

In the Jamf web interface when you view the extension attribute it appears to show a new changed/random password. However when you use the Jamf API to query the value the value returned is still the original unchanged value. This results in other scripts I use to fail because they read the wrong value.

The following is a simple script to read the LAPS extension attribute.

#!/bin/sh
udid=$(/usr/sbin/system_profiler SPHardwareDataType | /usr/bin/awk '/Hardware UUID:/ { print $3 }')
apiUser="username"
apiPass="password
extAttName="\"LAPS\""
apiURL="https://jamf.example.com"
localadminPass=$(curl -s -f -u $apiUser:$apiPass -H "Accept: application/xml" $apiURL/JSSResource/computers/udid/$udid/subset/extension_attributes | xpath -e "//extension_attribute[name=$extAttName]" | awk -F'<value>|</value>' '{print $2}' | tail -n +1 )
echo "result $localadminPass"

Note: The behaviour of xpath has changed in Big Sur, you now need to include the -e option as above and the number of lines to skip from the result has changed from 3 to 1.

[SimB4t1qbit]

@jelockwood We're experiencing the same issue as well. Have you had any luck since?

[jelockwood]

@SimB4t1qbit
I have recently left the role I was at that I was testing Big Sur and LAPS so cannot give a definite answer as to whether it reliably works but I think the xpath change to include the -e flag is the most important and possibly also the value in the tail command as per the example code I provided.

[SimB4t1qbit]

We were able to get LAPS working with Big Sur after making the following changes:

• Modifying the LAPS.sh script with: xpath -e + | tail -n +1 (thank you @jelockwood).
• Since these changes are incompatible with previous versions of macOS (< 11.0), we had to create a new policy, scoped only to Big Sur devices, that invokes the updated LAPS.sh. The remaining LAPS policies (i.e. the ones that do not make an API call to Jamf) did not need to be changed and are scoped to both Big Sur and non-Big Sur devices.
• It was discovered that our LAPS seed (initialization) password contained a $; removing this character was imperative in preventing mismatches between the LAPS password set on a device and the LAPS password reported in Jamf. I'm not entirely sure how this posed no issues for us with previous macOS releases (e.g. Mojave, Catalina), but after removing the $, LAPS is good to go for Big Sur.

[jelockwood]

@SimB4t1qbit
It would be possible to further modify the LAPS script so it detects the macOS version and then use an if/else to decide whether to use the xpath -e + | tail -n +1 or not. That is if macOS is less than 11 then use old command else use new command.

This would remove the need to scope different versions and greatly simplify matters.

I think it worth checking further, I think Catalina also supports the -e flag.

[SimB4t1qbit]

Excellent point, we will check this out @jelockwood.

[x089722]

Hi all,

I am still quite new to macOS, scripts & Jamf, but willing to learn

I am in the process of installing LAPS.
everything works except for one small thing
the user is created, a password is written into the extension but in the log it says

Script result: localadmin is a local user on the Computer
A Password was found in LAPS.
Password stored in LAPS is correct for localadmin.
Updating password for localadmin.
Reset password for localadmin
New password for localadmin is verified.

523(23) Failed writing body

Password: <dscl_cmd> DS Error: -14090 (eDSAuthFailed)
Error: LAPS password for localadmin is not correct!

The change also works without problems, but the same error is written to the log.
If you execute the manual trigger, you will be asked for a password.
I have already added xpath -e + | tail -n +1 to the Laps.sh.
what did i miss ?

many thanks for the help