getting prompted for admin credentials over jamfHelper window (osinstallersetupd)

[hkabik]

On 10.13.4 machines when doing an erase and install using this script I get prompted in the gui for admin credentials over the jamfHelper windows twice. If I quit the jamfHelper and enter my admin creds when prompted the process completes as expected.

The window asking for admin authentication says: "osinstallersetupd wants to make changes"

Obviously entering admin creds is behavior we wish to avoid here. Thanks!

[Hacksore]

@hkabik I think this has something to do with FV authenticated reboots. I was seeing the exact same issue when testing 10.13.4 with my updateUtil app.

@kc9wwh Have you ran into this in your testing?

[hkabik]

Is this because my users are non-admins?

If I added the logged in user to admin(80) in the script prior to the FV authenticated reboot piece, do you think that would cure this? Since it's just for an erase/install for re-DEPing devices there's not alot of fear with temporarily granting the admin rights and I can script it to strip them in the event of a failure.

[Hacksore]

@hkabik Maybe you're on to something. Our users are also not local admins so maybe the FV authenticated reboots are not playing nicely with standard accounts and 10.13.4 update?

[kc9wwh]

I have not seen this, but will test again and ensure I have a standard user.

[kc9wwh]

So I just ran it with a standard user on a non-filevault enabled system and no prompts for any creds. I can try FV enabled next, but curious @hkabik and @Hacksore ...

• Has the script been modified from the original?
• Are you running the script from Jamf Pro or locally on the system?

[hkabik]

No modification, running from JAMF Pro. This is 100% repeatable for me on 10.13.4 machines.

My machines are Filevaulted.

Actually I did change one thing... I would occasionally get errors on this step"jamfHelperPID=$(echo $!)" so I changed it to "jamfHelperPID=$(pgrep jamfHelper)" and it stopped the occasional failures.

[hkabik]

So adding in "dseditgroup -o edit -a $currentUser -t user admin" prior to the LaunchAgent bootstrap appears to cure the authentication dialog boxes.

But now, the installer just never seems to trigger. If I ssh into the box and ps -ax, I can see the process sitting there. But nothing ever happens. however if I manually kill it and run

jamfHelperPID=$(pgrep jamfHelper)

sudo "/Applications/Install macOS High Sierra.app/Contents/Resources/startosinstall" --applicationpath "/Applications/Install macOS High Sierra.app" --eraseinstall --nointeraction --pidtosignal $jamfHelperPID

while SSH'ed in it will start the install as expected, I can't understand why manually running it in SSH would be different than the script triggering it. These issues appear to be specific to 10.13.4, I don't feel like Apple really tested this startosinstall Helper Tool out completely. :/

[Hacksore]

@hkabik adding them to admin group prior to an update is not a solution but a band-aid.

@kc9wwh mine runs locally on the system as root. It's practically your script just missing a bunch of the configration options. (installOS.sh)

[kc9wwh]

I am able to replicate this issue now on macOS 10.13.4 with the system FileVault Enabled. It appears they've changed or added something to the osinstallersetupd LaunchAgent that gets called, specifically for doing the --eraseInstall option, but I am not sure what...

[hkabik]

I simply cannot get 10.13.4 to trigger an erase and install from jamf pro. It works if I run the command over ssh, but not coming from Jamf... :/ I even tried dropping it as a local script... if jamf triggers it startosinstall just stalls out. But if I ssh in and run it manually it works.

[Lotusshaney]

I had the same problem. Ive said before that I have this script as a post install script on a pkg and it works fine when called from a policy. I may well be a good enough workaround for you

[hkabik]

@Lotusshaney Thanks for the advise, tried the post install script method and same effect. the startosinstall process starts but never progresses. It seems the only way to get it to erase/install is if a user actually triggers it via terminal or ssh.

[Hacksore]

@kc9wwh Still seeing this issue with the FV authenticated reboots on 10.13.5, have you had a chance to test this?

[hkabik]

Yeah I can't get the erase/install to work on 10.13.4-5 filevaulted machines at all. It just never even gets the helper loaded. I've tried this as a policy, as a post install script, as an executable .command file. Nada.

[dkf2010]

I have the same problem. This problem is not due to this upgrade script nor FileVault. Same issue with the fresh installer from the macappstore and the startosinstall command (without the script). The installer.log says, that there is a problem creating an APFS partition.

[master-vodawagner]

Same Issue for me, if I execute the script locally it works but via Jamf if needs authentication. If I cancel that prompt I get an error in the install.log for creating an APFS partition

[USicilianU]

Hello, for my part I managed to eliminate this problem. I changed the line 362 userID = $ (/ usr / bin / id -u "$ {currentUser}") for LaunchAgent FV. I replaced "$ {currentUser}" by my user admin Jamf, for ex: userID = $ ( / usr / bin / id -u useradminjamf ). I hope my help can work for you too. Bye

[hkabik]

tried this, still prompted for admin creds.

[USicilianU]

@hkabik It is necessary to inform the root user which is used by the Self-Service, thus which is created by Jamf client with the enrollment. I had to insert a space at line 363 before /Library: Before: ....bootstrap gui/"${userID}"/Library/LaunchAge.... After: ....bootstrap gui/"${userID}" /Library/LaunchAge....

In my case, I launch the script via the Self-Service.

[jonlonergan]

I am seeing this issue for users with standard accounts who are FileVault encrypted upgrading from 10.13.6 to 10.14 in self service.

[cmlaven]

In testing we are seeing this on 10.12.x student machines (No FV and they are non-admins). It works great on our staff machines (they are local admins)

[scifiman]

I just wanted to add that I am seeing this when doing a 10.14 Mojave erase and install. The machine is NOT FileVault protected though the users do have secureTokens. So, it is possible it is in a deferment mode. If I put in the admin credentials, it proceeds fine, otherwise I get the APFS error in install.log.

[memile123]

I am also seeing this issue for users with standard accounts who are FileVault encrypted upgrading from 10.13.3 to 10.13.6. I get prompted for admin credentials but i can not type anything in either the username or the password fields to proceed.

[ripcon]

I am also seeing this upgrading from 1013.6 to 10.14.0 I have a zero in in the eraseInstall field and I still get prompted for credentials. just trying to upgrade. never seems to launch the installer.

[kc9wwh]

This does appear to be an issue with permissions that the startosinstall binary is requiring since this only seems to be popping up for standard users. I haven't completed my macOS 10.14 testing, but thus far with admin users, I have had a seamless experience both with upgrades and the eraseInstall option from 10.13 to 10.14 and in reverse.

[memile123]

Aside from scripting a way to add standard users to the admin group and then take them out, any thoughts or ideas on how we could bypass this? @kc9wwh Great scripting/logic

[Genesis2kx]

same scenario here. standard users with FV2 enabled trying to upgrade without that prompt via self-service in Jamf. Did anyone find a way?

[Lotusshaney]

You could try my fork if you like. It works for me

[donmontalvo]

Removed...my apologies, I shouldn't have posted this publicly.

[RJTablante]

Wow that was almost taken verbatim from my applecare case with them.

Those were my findings with 10.14 vs 10.14.1 installer differences but it seems to conflict with folks here that appeared to have tried upgrades to 10.14.1 and are still seeing the admin prompt (I don't anymore with the latest 10.14.1 installer).

Still would like to see what others are seeing here.

On Thu, Nov 29, 2018, 9:59 AM Don Montalvo <notifications@github.com wrote:

From Apple, regarding the osinstallersetupd authentication issue:

From: "Apple Enterprise Support " @services.apple.com> Date: Thursday, November 29, 2018 at 12:19 AM To: ...[snip]... Subject: [XXXXXXXXXXXX] Priority: High (osinstallersetupd authentication prompt when invoking through command line)

Hi Don,

Thanks for reaching out. We have figure out that there are differentiates for macOS 10.14 and 10.14.1 installer by the the following scenarios:

1. Upgrade to macOS 10.14 w/ a Standard User, FileVault enabled --> Prompt appears still and issue persists
2. Upgrade to macOS 10.14.1 w/ a Standard User, FileVault enabled --> Prompt does not appear, and upgrade completes

That said, we would suggest using the macOS 10.14.1 as the installer and following the steps to deploy. That should meet the zero touch updates/upgrade as needed.

...[snip]...

AppleCare Enterprise Technical Support Engineering Apple, Inc

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/kc9wwh/macOSUpgrade/issues/56#issuecomment-442863980, or mute the thread https://github.com/notifications/unsubscribe-auth/Ad6ty_o297nPV92nmNcS5ma8oRhE88wPks5uz_ZQgaJpZM4ULUrE .

[donmontalvo]

Removed...my apologies, I shouldn't have posted this publicly.

[RJTablante]

They crafted that boiler ate response with my findings that I sent to them, lol.

All good.

On Thu, Nov 29, 2018 at 1:11 PM Don Montalvo notifications@github.com wrote:

@RJTablante https://github.com/RJTablante I think what you mean is Apple may be using a boilerplate response. That's not a surprise, when they find an issue and respond to many people about it. My post was from a case we opened with Apple for this issue. Case number redacted.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/kc9wwh/macOSUpgrade/issues/56#issuecomment-442936194, or mute the thread https://github.com/notifications/unsubscribe-auth/Ad6tyzJV5kbODZ1SgH74TvWA9HDvJ4qVks5u0CNngaJpZM4ULUrE .

[ripcon]

I have just downloaded the 10.14.1 installer from apple and incorporated it in to the upgrade process. I still get the osinstallersetupd wants to make changes admin prompt.

[donmontalvo]

@RJTablante ah, makes sense. Yep does indeed seem so. 👍

[kernsb]

Just reporting in on this... seeing the behavior with non-admins, no FV enabled, performing upgrades to 10.14.2.

[donmontalvo]

We finally got around to working on this, we use 1 "Before" script to check if the current use has admin rights. If so, skip and proceed. Else elevate and echo username to a file:

upgradeRightsFix_elevate.sh

#!/bin/sh
# Check if current user is admin. If so exit. If not elevate
# and leave file containing user's LDAP name. 20181202 DM

folder1="/Library/COMPANY/UpgradeRightsFix"
file1="$folder1/taddedToAdminGroup.txt"
currentUser=$( python -c 'from SystemConfiguration import SCDynamicStoreCopyConsoleUser; import sys; username = (SCDynamicStoreCopyConsoleUser(None, None, None) or [None])[0]; username = [username,""][username in [u"loginwindow", None, u""]]; sys.stdout.write(username + "\n");' )

if [[ -e "$folder1" ]]
then
    echo "$folder1 folder exists."
else
    echo "$folder1 folder does not exist, creating it."
    mkdir -p "$folder1"
fi

echo "Checking if $currentUser is a member of admin group."
checkMembership=$( /usr/sbin/dseditgroup -o checkmember -m "$currentUser" admin )

if [[ "$checkMembership" == "yes $currentUser is a member of admin" ]]
then
    echo "$currentUser is a member of admin group, nothing to do."
    exit 0
else
    echo "$currentUser is not a member of admin group."
    echo "Adding $currentUser to admin group."
    /usr/sbin/dseditgroup -o edit -a "$currentUser" -t user admin
    /usr/bin/dsmemberutil flushcache
    echo "Echoing $currentUser to $file1."
    echo "$currentUser" > "$file1"
    if [[ -e "$file1" ]]
    then
        echo "$file1 exists"
        file1Content=$( cat "$file1" )
        echo "$file1 contains $file1Content."
        if [[ "$file1Content" == "$currentUser" ]]
        then
            echo "$file1 content matches current user $currentUser."
        else
            echo "$file1 content does not match current user $currentUser."
        fi
    else
        echo "$file1 does not exist."
    fi
fi

exit 0

Posting second script next...can't seem to post two scripts in one post.

[donmontalvo]

Then we use 1 script in a separate policy that runs when computer shows up online again as 10.13.6, to revoke that user's elevation.

upgradeRightsFix_revoke.sh (run once computer is successfully upgraded)

#!/bin/sh
# Check if current user is admin. If so exit. If not elevate
# and leave file containing user's LDAP name. 20181202 DM

folder1="/Library/COMPANY/UpgradeRightsFix"
file1="$folder1/taddedToAdminGroup.txt"
elevatedUser=$( cat "${file1}" )
file1Characters=$( printf "$$elevatedUser" | wc -m | sed -e 's/^[ \t]*//' )
checkMembership=$( /usr/sbin/dseditgroup -o checkmember -m "$elevatedUser" admin )

if [[ -e "$file1" ]]
then
    echo "$file1 exists."
    if [[ "$file1Characters" -ge 5 ]]
    then
        echo "$file1 contains $elevatedUser."
        echo "Revoking admin rights for $elevatedUser."
        /usr/sbin/dseditgroup -o edit -d "$elevatedUser" -t user admin
        /usr/bin/dsmemberutil flushcache
        echo "Checking if $elevatedUser rights have been revoked."
        if [[ "$checkMembership" == "no $elevatedUser is NOT a member of admin" ]]
        then
            echo "$elevatedUser admin rights revoked."
            exit 0
        else
            echo "Error revoking rights for $elevatedUser."
        fi
    else
        echo "$file1 exists but content is not usable."
    fi
else
    echo "$file1 does not exist."
fi

exit 0

Run these two scripts on a test computer while logged in as non admin user to test.

PS, The "/usr/bin/dsmemberutil flushcache" bit doesn't seem to result in the first confirmation returning a proper result. However the change does occur, and if you run this command again, you'll get the proper confirmation.

Hope this helps...thanks for all the great posts! Don

[thereal-kcsantos]

@donmontalvo We have a policy that runs the upgradeRightsFix_elevate.sh script to elevate access. then the macOSupgrade to upgrade macOS (10.14.2)

After, I created a separate policy for the to run the upgradeRightsFix_revoke.sh at login, but we're getting the following error:

6 Script result: cat: /Library/COMPANY/UpgradeRightsFix/upgradeRightsFix.txt: No such file or directory. Unable to find the user record /Library/COMPANY/UpgradeRightsFix/upgradeRightsFix.txt does not exist.

Any ideas on what we're doing wrong?

Does the Revoke script have to run after installation but before login, or something?

[Slowgrammer]

Thanks @donmontalvo ! Those scripts work great.

@KC-WhoizU there's a typo in the first (or second) script; the filenames don't line up. You'll need to make file1's filename match in both scripts. As written the first script writes out the non-admin username to taddedToAdminGroup.txt, then the second script tries to look for it in upgradeRightsFix.txt, which doesn't exist, resulting in your error.

[donmontalvo]

@KC-WhoizU and @Slowgrammer

Apologies for the typo, fixed!

[kenchan0130]

It is good news for all of you. It seems that this issue has been resolved by merging https://github.com/kc9wwh/macOSUpgrade/pull/97.

Thank you @taniguti!

And we want you to be careful a little bit, we are planning https://github.com/kc9wwh/macOSUpgrade/issues/100.