osinstallersetupd wants admin credentials

[maxm-ray]

I tried to upgrade from 10.13.6 to 10.14. Before restarting the script asks for the administrator credentials for the osinstallersetupd process.

Is there something wrong with the Script and 10.14?

[RJTablante]

Would also like to know if the script has been designed to work with both administrators and standard users as my previous attempts at implementing this script required work to elevate the standard user to admin to have this work as expected. Would like to use this for our users migration to Mojave but we have a primarily standard user base.

…

On Tue, Oct 9, 2018 at 9:01 AM Max ***@***.***> wrote: I tried to upgrade from 10.13.6 to 10.14. Before restarting the script asks for the administrator credentials for the osinstallersetupd process. Is there something wrong with the Script and 10.14? [image: img_0318] <https://user-images.githubusercontent.com/34512482/46671038-06a85300-cbd4-11e8-9e7b-c0a527639482.jpeg> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#74>, or mute the thread <https://github.com/notifications/unsubscribe-auth/Ad6ty8f0g0jN9tDkbOaLv72d30ou1jxlks5ujJ4QgaJpZM4XTOc2> .

[memile123]

This is most likely related to issue #56
I was able to test added a few users to the admin group and this worked perfectly..

[hcgtexas]

Any update/workaround on this issue? My environment is almost completely non-admin users, so this is not working for me.

[memile123]

Agreed @hcgtexas I'd really like to start deploying this out our users.. script works great along with composer..

[CMDRPhaedra]

yeah I ran into this issue today... would love a workaround.. all our users are non-admin so this doesn't work for me either.. :(

[RJTablante]

It appears this only occurs with FileVaulted standard users as it appears non-filevaulted standard users can upgrade with this script without issue. Not sure if this is only my experience, but it would be great if filevaulted standard users can leverage this script without having to elevate rights.

…

On Tue, Oct 30, 2018 at 12:52 PM CMDRPhaedra ***@***.***> wrote: yeah I ran into this issue today... would love a workaround.. all our users are non-admin so this doesn't work for me either.. :( — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#74 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/Ad6ty9iqA8FNa3CvhfjhYCopvq-sDtB6ks5uqIPYgaJpZM4XTOc2> .

[USicilianU]

Hi,

I am also in trouble where i have a park to update to macOS Mojave with standard user accounts and i also have the "osinstallersetupd" window asking for the admin password.
I will share with you the solution that I found and that works for me.

In the script "macOSUpgrade.sh" i check if the connected user is already admin with the dscl command. -read Groups / admin GroupMembership | cut -c 18- | grep "$ currentUser", if it does not have it I add it in "group admin" with the command dscl. -append groups / admin GroupMembership "$currentUser" and add the command dseditgroup -o edit -d "$ currentUser" -t user admin in the script of First boot "finishOSInstall.sh".

Thus the user becomes admin if he is not, and can run the installation process without problems.
After the update, during the first login the user becomes standard again.

I hope to have helped you with my solution.
By the way I wanted to congratulate @kc9wwh for this excellent script.

Excuse me for my English, it comes from Google translation.
Bye

[memile123]

@USicilianU Great! Do you mind sharing where you added that line? Was this a separate script?

[hcgtexas]

@USicilianU That sounds perfect! Do your changes have a check to make sure it won't remove admin if the user already had it before?

Can you share the whole edited script so I can see how you did it? I understand the logic, but I would like to see how you wrote it.

[USicilianU]

I put a condition that if the user is already admin I do not add to the next login the deletion of the user of the group admin. I will show you the script as soon as possible.

[kc9wwh]

What are peoples thoughts on this? I've thought of that, but am also worried that if something went wrong that the removal could not happen. I know I can't account for everything, but don't want to create a bigger issue either.

I also played around with integrating the SAP macOS Privileges app, but that isn't a perfect workflow either. ¯_(ツ)_/¯

[hcgtexas]

I like the add/remove admin rights workaround. There are obviously some things that can go wrong, but if the user doesn't even get prompted that they have admin rights, it is a lot less likely that they will abuse it.

Going through Jamf and checking admin rights to see if anyone has rights they shouldn't is a lot easier than going through the entire office and touching every single Mac.

[neilmartin83]

I second checking if the user is admin, then slipping them into the admin group and adding the necessary command to pull them out after the upgrade if they weren't in there to start with. If my understanding is correct, I would suggest evaluating whether the boot volume is APFS and if FileVault is enabled first and if both are yes then proceed to check the local user's admin group membership and do the deeds.

I think it's the only way we're going to get folks upgraded properly to 10.14.

[USicilianU]

Hi,
That's a good point @neilmartin83
I added conditions, if FileVault and On and if currentUser is Admin then do not delete currentUser from Group Admin after reboot.
If FileVault and On and if currentUser is not Admin then add to the Admin Group and delete CurrentUser from Group Admin after reboot.
If FileVault is Off, you do not need to know if currentUser is Admin.

Here are the tests I did and that works for me:
Updated to Mojave.
macOS High Sierra, FileVault On, currentUser is not Admin: the script runs correctly
macOS High Sierra, FileVault On, currentUser is Admin: the script runs correctly
macOS El Capitan, FileVault Off, currentUser is not Admin: the script runs correctly

The only problem I still have is check the currentUser if Admin.
For example, I am connected with the user "smith" who is not admin and there are several local users with the names "smith, smith1, smith2, etc ...", and for example smith2 is admin, and the grep finds smith2 because he finds smith in the word and passes the user admin script.

I have to find a way to make a grep with strict case sensitive.
smith should not be the same as smith2 with grep.

I copy you the script below:
macOSUpgrade_2.7.2.1.txt

[Lotusshaney]

Use
id -Gn $currentUser

This will list all the groups a user is in and check that

[Lotusshaney]

Another way that is exact is to use the -x option in grep. This is a whole line so you have to format DSCL's output into lines

/usr/bin/dscl . read /Groups/admin GroupMembership | tr ' ' '\n' | grep -x $currentUser

this will use tr to convert spaces to carriage returns and then grep's -x option will work as an exact match

[USicilianU]

Thanks @Lotusshaney.

I also found this method that works:
dseditgroup -o checkmember -m "$currentUser" -t group admin | grep "yes"

[Lotusshaney]

yeah that works too, in-fact you should probably use dseditgroup to handle the group adding and removal as dscl is not really the correct Apple way anymore

[Lotusshaney]

Here is my go at the problem, I use a touch file in the users home folder and then get the LaunchDaemon to demote the user and clean up if its present.
macOSUpgrade_dan.txt

[USicilianU]

Hi,
I had to add at the end of the script the deletion of admin rights with a condition, if the installation fails following Requirements Not Met.

if [[ -z "$CheckUserAlreadyAdmin" ]]; then
/usr/sbin/dseditgroup -o edit -d "$currentUser" -t user admin
fi

[neilmartin83]

Awesome - I recommend using this method to get the current logged in user:

currentUser=$( scutil <<< "show State:/Users/ConsoleUser" | awk -F': ' '/[[:space:]]+Name[[:space:]]:/ { if ( $2 != "loginwindow" ) { print $2 }}' )

See http://erikberglund.github.io/2018/Get-the-currently-logged-in-user,-in-Bash/ for details - it's based on Ben Toms' blog post from a few years back which used Python to do it.

[riddl0rd]

Had tip from grahamrpugh It's the only line that does something affecting the user level, everything else is just running as root. when I comment it out the upgrade process runs perfect

/ /bin/launchctl bootstrap gui/"${userID}" /Library/LaunchAgents/com.apple.install.osinstallersetupd.plist

[Lotusshaney]

The problem with removing that line is it will not do an unattended reboot of a FileVault system. The user will have to enter there password at the FileVault login.

[donmontalvo]

Apple have recommended this command to accommodate computers that have Fast User Switching enabled:

current_user=$( 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");' )

FWIW, we are using v2.6.1 of this script, updating/upgrading users to 10.13.6 and are seeing this prompt when current user is not admin:

[donmontalvo]

I realize now 2.7.2.1 is the current version, we are on 2.6.1...before shifting gears and moving to this new version, is the above issue resolved in 2.7.2.1?

[USicilianU]

Hi @donmontalvo ,
Yes, this message also appears with script version 2.7.2.1

[ferriterj1]

I am getting the "osinstallersetupd" popup in my environment where everyone is a standard user. None of my machines are filevaulted. Any reason why this would be happening?

[donmontalvo]

Opened a ticket with Jamf to see if they have any ideas. They echoed what was said on this issue thread, temporarily giving the current user admin rights, until the update/upgrade is done, then revoking admin rights when the update/upgrade is done. For understandable reasons this is outside the scope of what this script is designed to do, more of an issue that Apple may need to weigh in on, so we're opening a support ticket to see if this is a bug Apple needs to fix.

[memile123]

Meh.. it might be long before you get a resolution/response . We thought about going that route as well. So far here’s what has worked for us.

-Use this script along with a temp admin script that runs prior to the installer app gets placed
-We already had a demote non approved admins to standard script that runs on login in placed, so once the OS installation finished and the machine checked in, user would be demoted.

This has worked for High Sierra and Mojave 14.1

[fishd72]

Opened a ticket with Jamf to see if they have any ideas. They echoed what was said on this issue thread, temporarily giving the current user admin rights, until the update/upgrade is done, then revoking admin rights when the update/upgrade is done. For understandable reasons this is outside the scope of what this script is designed to do, more of an issue that Apple may need to weigh in on, so we're opening a support ticket to see if this is a bug Apple needs to fix.

Personally, if your place of work operates under a "no one gets admin rights" kind of policy then this isn't going to fly as a solution. I'd say removing the authenticated restart and prompting the user for their password is a better workaround.

[neilmartin83]

Agree with @fishd72 - perhaps having auth restart configurable with a parameter, like the others in the script, to make it easier for folks to turn on/off. Then admins can decide to use that as a workaround and have control over it.

[fishd72]

I recently removed the lines relating to running the launch agent and confirmed that if you're using the script to erase the device and install a fresh copy of the OS then it works as expected. If you're doing an in place upgrade, you're prompted half way through to enter your FileVault credentials but then the upgrade completes successfully.

[krispayne]

@Lotusshaney's updated script worked for my standard user with FV going from 10.13.6 to 10.14.1. It was hanging here:

2019-01-17 08:10:37-08 username osinstallersetupd[9411]: ensurePrebootVolumeForDisk: ensureRecoveryBooter instantly failed with error: -69863
2019-01-17 08:10:37-08 username osinstallersetupd[9411]: Operation queue failed with error: Error Domain=com.apple.OSInstallerSetup.error Code=224 "Could not create a preboot volume for APFS install." UserInfo={NSLocalizedDescription=Could not create a preboot volume for APFS install.}

This is where osinstallersetup would prompt for admin credentials for us.

After running @Lotusshaney's script, the user was not prompted, the install was successful, and they were removed from admin on first boot

[memile123]

@krispayne Nice! i cant seem to find his script or pull request with code changes.

[krispayne]

@memile123 ‘‘Tis but a link in a comment in this thread.

[Lotusshaney]

I did a pull request awhile ago but it got cancelled

[Lotusshaney]

It’s pull #86

[krispayne]

Either in this thread or the other I think that the idea of elevating then demoting wasn't wholly agreed upon since it's possible that the demotion wouldn't work all of the time, that and more strict environments where even the temporary elevation was considered policy violation.

That being said, it worked flawlessly this morning on a very troublesome machine.

[Lotusshaney]

He is a slightly updated version of the script the does the demote without requiring a user to be logged in. Give this a try if you like.

https://github.com/Lotusshaney/macOSUpgrade/blob/master/macOSUpgrade.sh

[kenchan0130]

It seems that this problem do not occur when I tried to upgrade to mojave with 10.14.3 installer.

[hcgtexas]

Very interesting. I will test that today. Can anyone else confirm this is not an issue with 14.3?

[kenchan0130]

@hcgtexas Thank you for your response.
I think that it can not be confirmed by my environment alone, so it would be nice to have some people try.

[hcgtexas]

Still asking me for admin credentials with the 10.14.3 installer

[kenchan0130]

That's unfortunate.
Perhaps my environment was special. I'm sorry.

[kenchan0130]

It is good news for all of you.
It seems that this issue has been resolved by merging #97.

Thank you @taniguti!

And we want you to be careful a little bit, we are planning #100.