+5I am looking to see if there is anything like the Make Me an Admin script that will work in macOS Ventura. The current script does not work in Ventura. I don't get any report of errors just doesn't make the account an admin account.
I do know about Privileges. I wanted something I can control the time the account is an admin. I only want to allow the accounts be admin for 30 minutes.
+25@sara_mccullar I don't have a recommendation to replace Make Me an Admin, but PrivilegesDemoter is a companion tool for Privileges you might want to check out. It is intended to prevent/discourage users from retaining admin rights longer than necessary.
+14@sara_mccullar You can try this. It's really dumb though. Just put it in Self Service.
#!/bin/bash
# Make Me Admin
# Brandon Woods
# January 2023
# A really dumb version of "Make Me Admin" written in 7 mintues. Whavever, it works, I guess.
# Determine Current User
currentUser=$( scutil <<< "show State:/Users/ConsoleUser" | awk '/Name :/ && ! /loginwindow/ { print $3 }' )
# Promote user to admin
sudo dseditgroup -o edit -a "$currentUser" -t user admin
# Sleep for 30 minutes (I think that's 30 minutes in seconds, whatever)
sleep 1800
# Demote user to standard
sudo dseditgroup -o edit -d "$currentUser" -t user admin
exit 0 ## Success
exit 1 ## Failure
+8@sara_mccullar what is the goal of the admin role?
If your goal is to automate the updates of macOS computers with standard user accounts in your fleet to Ventura (or from macOS 13.0 - 13.2) by making them admins for 30min then there are better ways to do this IMO.
My recommendation is to use a combination of tools;
1. Nudge
a. Link to the film which shows my configuration
b. Link to film which shows my configuration for this tool
c. Link to a film that shows how I combine these configurations.
Hope that helps!
+5@sara_mccullar what is the goal of the admin role?
If your goal is to automate the updates of macOS computers with standard user accounts in your fleet to Ventura (or from macOS 13.0 - 13.2) by making them admins for 30min then there are better ways to do this IMO.
My recommendation is to use a combination of tools;
1. Nudge
a. Link to the film which shows my configuration
b. Link to film which shows my configuration for this tool
c. Link to a film that shows how I combine these configurations.
Hope that helps!
We have some users who need admin rights periodically for the work they are doing. It's not for software updates. We want to be able to get all our users to have a standard account. Those that need to be able to be admin accounts can have that access through a self service option or app.
+7We have some users who need admin rights periodically for the work they are doing. It's not for software updates. We want to be able to get all our users to have a standard account. Those that need to be able to be admin accounts can have that access through a self service option or app.
Have you looked at Privileges?
+5Have you looked at Privileges?
Yes, I just need it to revoke the admin rights after a certain amount of time without user interaction.
+8Yes, I just need it to revoke the admin rights after a certain amount of time without user interaction.
Got it. My proposed solution is not going to work for you.
@Utilizator s solution is more appropriate.
https://github.com/SAP/macOS-enterprise-privileges
Best of luck!
+5So here is the thing with Privileges, yes it allows the user to become an admin. I can only get the time limit to set if I use the toggle feature when you right click on the dock icon. Now most of our users are not going to do that. They will just click the dock icon and hit request privileges. I do believe that after maybe 48 hours (honestly wasn't keeping track for that long period) it did revert the user account back to a standard account.
Now I know there is the Privileges Demoter. All that does is give a pop up reminder to extend or remove the admin privilege. We have had people who could ignore the old nudge (pre big sur) and never run the updates.. Those people are most likely not going to be ones needing admin rights, but I want something that will take away those rights in 30 minutes.
So unless someone knows how to get the privileges dock icon to open to toggle which activates the timer, it's not going to work for me.
+9So here is the thing with Privileges, yes it allows the user to become an admin. I can only get the time limit to set if I use the toggle feature when you right click on the dock icon. Now most of our users are not going to do that. They will just click the dock icon and hit request privileges. I do believe that after maybe 48 hours (honestly wasn't keeping track for that long period) it did revert the user account back to a standard account.
Now I know there is the Privileges Demoter. All that does is give a pop up reminder to extend or remove the admin privilege. We have had people who could ignore the old nudge (pre big sur) and never run the updates.. Those people are most likely not going to be ones needing admin rights, but I want something that will take away those rights in 30 minutes.
So unless someone knows how to get the privileges dock icon to open to toggle which activates the timer, it's not going to work for me.
Hi @sara_mccullar this one is a paid solution. Maybe this is interesting to you:
https://www.adminbyrequest.com/
https://www.adminbyrequest.com/docs/Mac-Client
+4I'm a bit late to this party, but I'm looking to do exactly the same thing (with making the default time 15 minutes instead of 30).
Looking at Privileges, it does seem to come with a CLI, where you can run commands as a standard user to add or remove elevation. I think in theory you could create a LaunchAgent that runs every 30 minutes that will run the CLI option to remove the admin rights (scroll down to "How do I use Privileges.app in a script or from the command line?") :
The specific command to remove the admin permissions for the currently logged in user:
/Applications/Privileges.app/Contents/Resources/PrivilegesCLI --remove
I'll be giving this a try and will let you know how it goes.
+9Hi @rcoleman check out the blog post from Rich Trouton regarding the behavior:
https://derflounder.wordpress.com/2022/07/22/privileges-app-and-time-limited-admin/
And the demoter github project:
https://github.com/sgmills/PrivilegesDemoter
Hope this helps :)
+4Many thanks @pkleiber. I had already seen these posts. Problem with Demotor is that it 'requests' if you want to remove the rights. I don't want to give the users that option, I just want to remove them :)
I've created a LaunchDaemon which on the face of it appears to work. I've had to use a LaunchDaemon over an agent for a few reasons, but mainly so that I can run the script as root to obtain the following:
One issue is that the Privileges CLI only works when run under a user context, so I've had to use 'sudo -u' when wanting to run these commands to run as another user.
I've not tested this thoroughly, but it appears to work. For my own settings, I've set the Daemon to run every 3 minutes, so it has the potential to go over the 15 minutes which we want to adhere to, but that's not a big issue. The Daemon runs the script below. Obviously, Privileges needs to already be installed:
#!/bin/bash
# Function for creating timestamp for logging purposes
timestamp() {
while read -r line
do
time_stamp=$(date)
/bin/echo "[$time_stamp] $line"
done
}
########## JUST EDIT THESE VALUES ##################
###########################################################
# The allowed time in seconds - used for working out the time difference
ALLOWED_TIME_SECONDS=900
# The allowed time in minutes - used for better readability within the output / log
ALLOWED_TIME_MINUTES=$((ALLOWED_TIME_SECONDS/60))
# Location of custom log
LOGFILE="/Library/Logs/privileges-daemon.log"
###########################################################
# Check to see if log exists. If so then delete as we only require a log of the last run
if [ -f "$LOGFILE" ]
then
rm -f "$LOGFILE"
fi
# See if we have a user logged in
CURRENT_USER=$(echo "show State:/Users/ConsoleUser" | scutil | awk '/Name :/ && ! /loginwindow/ { print $3 }')
# If no user logged in, then see who the last logged in user was and set this to the current user
if [ -z "$CURRENT_USER" ]; then
/bin/echo "No user currently logged in. Getting last logged in user..." | timestamp 2>&1 | tee -a "$LOGFILE"
# Get the last logged in username
CURRENT_USER=$(last grep console | cut -d " " -f1 | head -n 1)
/bin/echo "Last logged in user was $CURRENT_USER" | timestamp 2>&1 | tee -a "$LOGFILE"
else
/bin/echo "$CURRENT_USER is currently logged in." | timestamp 2>&1 | tee -a "$LOGFILE"
fi
# Make sure Privileges is installed
PRIVILEGES_CLI="/Applications/Privileges.app/Contents/Resources/PrivilegesCLI"
if [ ! -f "$PRIVILEGES_CLI" ]; then
/bin/echo 'Privileges does not appear to be installed! Quitting script.' | timestamp 2>&1 | tee -a "$LOGFILE"
exit 1;
fi
# Get the currently logged in users account status. Need to re-direct all output in order to capture
STATUS=$(sudo -u "$CURRENT_USER" "$PRIVILEGES_CLI" --status 2>&1)
if [[ "$STATUS" == *"standard"* ]]; then
/bin/echo "$CURRENT_USER does not appear to be an admin. Quitting script." | timestamp 2>&1 | tee -a "$LOGFILE"
exit 0;
elif [[ "$STATUS" == *"admin"* ]]; then
/bin/echo "$CURRENT_USER appears to be an admin." | timestamp 2>&1 | tee -a "$LOGFILE"
# Get the last time the 'current user' elevated their permissions
LAST_ADMIN_ENTRY=$(log show --style syslog --predicate 'process == "corp.sap.privileges.helper" && eventMessage CONTAINS "SAPCorp"' | grep "$CURRENT_USER" | grep admin | tail -n 1 | cut -d. -f1)
# If it's null then there's been an issue with reading the log file, or since script has begun executing admin privileges may have been revoked. Just quit.
if [ -z "$LAST_ADMIN_ENTRY" ]; then
/bin/echo "Cannot obtain time stamp from the last time permissions were elevated. It's possible that user permissions have reverted to 'standard' since this script started executing. Please manually check permissions. Quitting."
exit 1;
else
# Get current date and time
NOW_EPOCH=$(date -j -f "%Y-%m-%d %H:%M:%S" "$(date +"%Y-%m-%d %H:%M:%S")" +"%s")
# Convert the last executed time to epoch
LAST_ADMIN_ENTRY_EPOCH=$(date -j -f "%Y-%m-%d %H:%M:%S" "$LAST_ADMIN_ENTRY" +%s)
# Get the difference in the time
DIFFERENCE_IN_SECONDS=$((NOW_EPOCH-LAST_ADMIN_ENTRY_EPOCH))
# For log readability, convert difference to minutes
DIFFERENCE_IN_MINUTES=$((DIFFERENCE_IN_SECONDS/60))
# If it's longer than the allowed time then remove the rights
if [ "$DIFFERENCE_IN_SECONDS" -gt "$ALLOWED_TIME_SECONDS" ]; then
/bin/echo "$CURRENT_USER has been an admin for over $ALLOWED_TIME_MINUTES minutes. Amount of time since activated - $DIFFERENCE_IN_MINUTES minutes. Removing permissions..." | timestamp 2>&1 | tee -a "$LOGFILE"
sudo -u "$CURRENT_USER" "$PRIVILEGES_CLI" --remove
# Get the status again so we can make sure permissions have been removed
STATUS=$(sudo -u "$CURRENT_USER" "$PRIVILEGES_CLI" --status 2>&1)
if [[ "$STATUS" == *"standard"* ]]; then
/bin/echo "$CURRENT_USER successfully set to standard permissions." | timestamp 2>&1 | tee -a "$LOGFILE"
exit 0;
else
/bin/echo "There has been an issue revoking admin permissions for $CURRENT_USER. Please manually check to make sure permissions have been revoked." | timestamp 2>&1 | tee -a "$LOGFILE"
exit 1;
fi
else
/bin/echo "Permissions have been elevated but still within the 15 minute window. Amount of time since activated - $DIFFERENCE_IN_MINUTES minutes. Quitting script." | timestamp 2>&1 | tee -a "$LOGFILE"
exit 0;
fi
fi
else
/bin/echo "There has been a problem obtaining the status of $CURRENT_USER's account. No changes have occurred." | timestamp 2>&1 | tee -a "$LOGFILE"
exit 1;
fi
+4Just to say, I've expanded the script above and just posting on the off-chance it's helpful to anyone else. The script is triggered by a LaunchDaemon that executes every 3 minutes.
The main issues I had with the script above is that I didn't want to remove admin permissions from any IT support accounts (we have multiple different schools, each with their own admin accounts), so I had to come up with a method that didn't revoke permissions from these accounts.
Secondly, I noticed an issue with the script I posted above in that if a user elevated their permissions and then logged out, and then a different user logged in and elevated their permissions, then the first user would be left with permanent admin permissions, as the script only revoked permissions for the last user to elevate using Privileges. I got around this by only applying the 15 minute timer to the last user, and just removing permissions immediately for the previous user. In our case, this is specifically for staff devices, so it's unlikely that more than 2 users would login to the same device within 15 minutes, but if this is the case then the script above could be modified to include more than the last 2 users to elevate their permissions.
The usernames of the IT support accounts in the script would need to be changed to match your own.
#!/bin/bash
# This script removes admin rights from the last account that elevated their permissions using the Privileges app:
# https://github.com/SAP/macOS-enterprise-privileges
# It is run by a LaunchDaemon that executes every 3 minutes.
# It waits at least 15 minutes since the permissions were elvated before removing the admin permissions for the last non IT Support account that used Privileges to elevate their permissions.
# As the script is run every 3 minutes (as set by the LaunchDaemon), there is a possibility that admin rights will persist up to 18 minutes.
# The username of the last user that elevated their permissions using the Privileges app is taken from the syslog using the recommend command from Privileges developers:
# https://github.com/SAP/macOS-enterprise-privileges/wiki/Frequently-Asked-Questions#how-do-i-access-logs-for-privileges
#
# Possible issue with this workflow:
# 1st user elevates their permissions and immediately logs out. 15 minute timer starts.
# Within the 15 minutes, 2nd user logs in and elevates their permissions.
# 1st user that elevated their permissions will end up with permanent admin rights, as this workflow only revokes permissions for the last user who elevated their permissions using Privileges.
# To get around this, the script will extract the last 2 users that elevated their permissions. Only the last user will have the 15 minute countdown. The previous user (if different) will just have their permissions automtically revoked.
# Number can be increased if only 1 previous user isn't enough, but it's unlikely you would have 3 different staff members login to a staff built device within a 15 minute window.
##################### GLOBALS #############################
# The allowed time in seconds - used for working out the time difference
ALLOWED_TIME_SECONDS=900
# The allowed time in minutes - used for better readability within the output / log
ALLOWED_TIME_MINUTES=$((ALLOWED_TIME_SECONDS/60))
# Location of custom log
LOGFILE="/Library/Logs/privileges-daemon.log"
###########################################################
# Function for obtaining timestamp
timestamp() {
while read -r line
do
TIMESTAMP=$(date)
echo "[$TIMESTAMP] $line"
done
}
# Function for checking local IT Support accounts to make sure admin rights are not removed from these accounts. If you only have one IT support account then no need to declare array
check_local_IT_support_accounts() {
# Get list of local accounts
LOCAL_ACCOUNTS=$(dscl . list /Users | grep -v -e '_' -e 'root' -e 'daemon' -e 'nobody')
# Declare array of local IT Support accounts - ************* EDIT THIS TO MATCH YOUR OWN IT SUPPORT ACCOUNTS *************
IT_SUPPORT_ACCOUNTS=("ITSupportAccount1" "ITSupportAcount2" "ITSupportAccount3")
# If any local account matches an IT support account, then make sure it's still an admin
for LOCAL_ACCOUNT in $LOCAL_ACCOUNTS; do
for IT_SUPPORT_ACCOUNT in "${IT_SUPPORT_ACCOUNTS[@]}"; do
if [ "$LOCAL_ACCOUNT" = "$IT_SUPPORT_ACCOUNT" ]; then
dscl . -append /groups/admin GroupMembership "$LOCAL_ACCOUNT"
fi
done
done
}
################## MAIN #################
# Check to see if log exists. If so then delete as we only require a log of the last run
if [ -f "$LOGFILE" ]
then
rm -f "$LOGFILE"
fi
# Make sure Privileges is installed
PRIVILEGES_CLI="/Applications/Privileges.app/Contents/Resources/PrivilegesCLI"
if [ ! -f "$PRIVILEGES_CLI" ]; then
/bin/echo 'Privileges does not appear to be installed! Quitting script.' | timestamp 2>&1 | tee -a "$LOGFILE"
exit 1;
fi
# Parsing syslog, get the last 2 instances where a user that was not an IT support account elevated their permissions using the Privileges app. Any support account usernames should be added to the 'grep -v' part so they can be excluded
# ************* EDIT THIS TO MATCH YOUR OWN IT SUPPORT ACCOUNTS *************
LAST_TWO_LOG_ENTRIES=$(log show --style syslog --predicate 'process == "corp.sap.privileges.helper" && eventMessage CONTAINS "SAPCorp"' | grep admin | grep -v -e "ITSupportAccount1" -e "ITSupportAcount2" -e "ITSupportAccount3" | tail -n 2)
# If there are no log entries for non IT Support accounts then exit
if [ -z "$LAST_TWO_LOG_ENTRIES" ]; then
/bin/echo 'Cannot obtain a log entry for a non IT Support account elevating their permissions using Privileges. Perhaps Privileges has never been used? You may need to manually check permissions. No permissions have been revoked. Quitting.' | timestamp 2>&1 | tee -a "$LOGFILE"
exit 0;
fi
# Separate the last 2 log entries
LAST_TWO_LOG_ENTRIES_SEPARATED=$(echo "$LAST_TWO_LOG_ENTRIES" | awk -F 'rights' '{print $1 FS "."}')
#LAST_TWO_LOG_ENTRIES_SEPARATED=$(echo "$LAST_TWO_LOG_ENTRIES" | sed 's/rights./\\n/g' | awk '{$1=$1};1')
echo "Last 2 log entries:" | timestamp 2>&1 | tee -a "$LOGFILE"
echo "$LAST_TWO_LOG_ENTRIES_SEPARATED" | tee -a "$LOGFILE"
# Obtain the usernames from these entries. Store in temp variable
LAST_TWO_USERS_=$(echo "$LAST_TWO_LOG_ENTRIES" | sed -e 's/.*User \\(.*\\) has.*/\\1/')
# Remove the space to keep log output on one line
LAST_TWO_USERS="${LAST_TWO_USERS_//$'\\n'/ }"
echo "Last 2 users: $LAST_TWO_USERS" | timestamp 2>&1 | tee -a "$LOGFILE"
# Get the last log entry
LAST_LOG_ENTRY=$(echo "$LAST_TWO_LOG_ENTRIES_SEPARATED" | tail -n1)
echo "Last log entry: $LAST_LOG_ENTRY" | timestamp 2>&1 | tee -a "$LOGFILE"
# Get the last user
LAST_USER=$(echo "$LAST_LOG_ENTRY" | sed -e 's/.*User \\(.*\\) has.*/\\1/')
echo "Last user: $LAST_USER" | timestamp 2>&1 | tee -a "$LOGFILE"
# We only care about running the 15 minute timer for the last person that elevated their permissions using Privileges. If there is a different previous user then just remove their admin permissions
# For each of the last 2 users
for USER in $LAST_TWO_USERS; do
# If the specific user is not the last user
if [ ! "$USER" = "$LAST_USER" ]; then
# Revoke permissions
echo "$USER elevated permissions prior to the last user to elevate. Removing permissions... " | timestamp 2>&1 | tee -a "$LOGFILE"
sudo -u "$USER" "$PRIVILEGES_CLI" --remove
fi
done
# Just get the time of the last entry
LAST_LOG_ENTRY_TIME=$(echo "$LAST_LOG_ENTRY" | cut -d. -f1)
# Get the account status of the last user that elevated their permissions using Privileges. Need to re-direct all output in order to capture
STATUS=$(sudo -u "$LAST_USER" "$PRIVILEGES_CLI" --status 2>&1)
# If it's already standard then just quit
if [[ "$STATUS" == *"standard"* ]]; then
/bin/echo "The last non IT Support account to use Privileges - $LAST_USER is already set to standard permissions." | timestamp 2>&1 | tee -a "$LOGFILE"
exit 0;
# Else we need to check if they have had admin permissions for over 15 minutes
else
# Get current date and time
NOW_EPOCH=$(date -j -f "%Y-%m-%d %H:%M:%S" "$(date +"%Y-%m-%d %H:%M:%S")" +"%s")
# Convert the last executed time to epoch
LAST_ADMIN_ENTRY_EPOCH=$(date -j -f "%Y-%m-%d %H:%M:%S" "$LAST_LOG_ENTRY_TIME" +%s)
# Get the difference in the time
DIFFERENCE_IN_SECONDS=$((NOW_EPOCH-LAST_ADMIN_ENTRY_EPOCH))
# For log readability, convert difference to minutes
DIFFERENCE_IN_MINUTES=$((DIFFERENCE_IN_SECONDS/60))
# If it's longer than the allowed time then remove the rights
if [ "$DIFFERENCE_IN_SECONDS" -gt "$ALLOWED_TIME_SECONDS" ]; then
/bin/echo "$LAST_USER has been an admin for over $ALLOWED_TIME_MINUTES minutes. Amount of time since activated - $DIFFERENCE_IN_MINUTES minutes. Removing permissions..." | timestamp 2>&1 | tee -a "$LOGFILE"
sudo -u "$LAST_USER" "$PRIVILEGES_CLI" --remove
# Get the status again so we can make sure permissions have been removed
STATUS=$(sudo -u "$LAST_USER" "$PRIVILEGES_CLI" --status 2>&1)
if [[ "$STATUS" == *"standard"* ]]; then
/bin/echo "$LAST_USER successfully set to standard permissions." | timestamp 2>&1 | tee -a "$LOGFILE"
check_local_IT_support_accounts
exit 0;
else
/bin/echo "There has been an issue revoking admin permissions for $LAST_USER. Please manually check to make sure permissions have been revoked." | timestamp 2>&1 | tee -a "$LOGFILE"
check_local_IT_support_accounts
exit 1;
fi
else
/bin/echo "Permissions for $LAST_USER have been elevated but still within the 15 minute window. Amount of time since activated - $DIFFERENCE_IN_MINUTES minutes. Quitting script." | timestamp 2>&1 | tee -a "$LOGFILE"
check_local_IT_support_accounts
exit 0;
fi
fi
+3@sara_mccullar You can try this. It's really dumb though. Just put it in Self Service.
#!/bin/bash
# Make Me Admin
# Brandon Woods
# January 2023
# A really dumb version of "Make Me Admin" written in 7 mintues. Whavever, it works, I guess.
# Determine Current User
currentUser=$( scutil <<< "show State:/Users/ConsoleUser" | awk '/Name :/ && ! /loginwindow/ { print $3 }' )
# Promote user to admin
sudo dseditgroup -o edit -a "$currentUser" -t user admin
# Sleep for 30 minutes (I think that's 30 minutes in seconds, whatever)
sleep 1800
# Demote user to standard
sudo dseditgroup -o edit -d "$currentUser" -t user admin
exit 0 ## Success
exit 1 ## Failure
Hey mate, i like this approach. Can you please expand on why it's "dumb"?
@sara_mccullar what is the goal of the admin role?
If your goal is to automate the updates of macOS computers with standard user accounts in your fleet to Ventura (or from macOS 13.0 - 13.2) by making them admins for 30min then there are better ways to do this IMO.
My recommendation is to use a combination of tools;
1. Nudge
a. Link to the film which shows my configuration
b. Link to film which shows my configuration for this tool
c. Link to a film that shows how I combine these configurations.
Hope that helps!
Hey @bcrockett,
I appreciate the detailed list there regarding using Nudge and Erase-install.
I took a look at your video here: https://www.youtube.com/watch?v=xS8L0rf-1FI
I am using version 30.1, and it looks like we no longer need to pass --current-user as the script is able to pick up that a user is logged in. I am also safely assuming this since in the Wiki there is no reference to using --current-user. Looks like 30.2 was just released so I might test with that.
I am actually using the exact same workflow in your video (Nudge + Erase-install). I have had little to no luck though getting standard users to update their devices via self-service policy using erase-install, and having Nudge point to that execution policy.
In testing, I have had to resort to giving the user temporary admin access. A good portion of our users are on Monterey, but some users are on Ventura, and they have needed temp admin access to update with erase-install. I have been testing on Silicon macbookpros with users but every single test with a silicon macbook pro times out after the standard user is prompted for a password by erase-install. Intel devices with admin users update just fine.
I have been resorting to the makemeadmin script for elevating permissions which seems to be working for Ventura. I just don't want users to be prompted that they will receive admin so I might edit the script. My only issue now is that I don't want to remove admin from users who already have admin on their local machine (engineers mostly)
I opened up a discussion on erase-install here: https://github.com/grahampugh/erase-install/discussions/424
The issue looked very similar to another issue on the github page here: https://github.com/grahampugh/erase-install/issues/412 but in my case the volume owner's password just doesn't work at all when erase-install prompts the user for their password. The user is in fact a volume owner, standard user but it just won't go through with the update and it times out after 60 minutes.
This is basically what I think my workflow would be like:
1. Deploy Nudge
2. Have nudge point to policy that runs temp admin first > Then erase-install
Wondering if you had any thoughts on this?
+8Hey @bcrockett,
I appreciate the detailed list there regarding using Nudge and Erase-install.
I took a look at your video here: https://www.youtube.com/watch?v=xS8L0rf-1FI
I am using version 30.1, and it looks like we no longer need to pass --current-user as the script is able to pick up that a user is logged in. I am also safely assuming this since in the Wiki there is no reference to using --current-user. Looks like 30.2 was just released so I might test with that.
I am actually using the exact same workflow in your video (Nudge + Erase-install). I have had little to no luck though getting standard users to update their devices via self-service policy using erase-install, and having Nudge point to that execution policy.
In testing, I have had to resort to giving the user temporary admin access. A good portion of our users are on Monterey, but some users are on Ventura, and they have needed temp admin access to update with erase-install. I have been testing on Silicon macbookpros with users but every single test with a silicon macbook pro times out after the standard user is prompted for a password by erase-install. Intel devices with admin users update just fine.
I have been resorting to the makemeadmin script for elevating permissions which seems to be working for Ventura. I just don't want users to be prompted that they will receive admin so I might edit the script. My only issue now is that I don't want to remove admin from users who already have admin on their local machine (engineers mostly)
I opened up a discussion on erase-install here: https://github.com/grahampugh/erase-install/discussions/424
The issue looked very similar to another issue on the github page here: https://github.com/grahampugh/erase-install/issues/412 but in my case the volume owner's password just doesn't work at all when erase-install prompts the user for their password. The user is in fact a volume owner, standard user but it just won't go through with the update and it times out after 60 minutes.
This is basically what I think my workflow would be like:
1. Deploy Nudge
2. Have nudge point to policy that runs temp admin first > Then erase-install
Wondering if you had any thoughts on this?
@chrisfromgh this is a good background.
I have updates on my fleet on hold for about 30 days due to the start of the school year.
After which I will update my erase install software and test it with nudge again.
Once I have test results I will let you know. And hopefully, make an updated video.
Thanks, ~ B
+8@chrisfromgh this is a good background.
I have updates on my fleet on hold for about 30 days due to the start of the school year.
After which I will update my erase install software and test it with nudge again.
Once I have test results I will let you know. And hopefully, make an updated video.
Thanks, ~ B
Chris,
I have updates for you based on the results from my fleet.
On 09/08/2023 I updated my JSS policy to use version 30.2 of the erase-install script.
Next, I tested it on my lab computers and it worked for updates from macOS13.4 to macOS13.5.2. These are standard user accounts.
They do not have an admin privilege or temporary elevation to one.
After that, I updated my Nudge setting and set update out fleet-wide to a smart group that includes all computers except ones on macOS 13.5.2
As of today, this workflow has worked seamlessly on over 100 M1 MacBooks.
However, it has not worked perfectly on all of them.
The ones that are coming in for service are newly deployed and do not have tokens. Compounding matters, I have found that the local admin account does not have a token either.
For that reason, I am temporarily using this script token for the problem computers one by one.
#!/bin/bash
#get logged in user
currentuser=$(/bin/ls -la /dev/console | /usr/bin/cut -d ' ' -f 4)
user_entry=""
#prompt user for their password
while [ "$user_entry" = "" ] ; do
user_entry=$(osascript -e '
tell application "Finder"
activate
try
display dialog "Please enter local password" with title "Assign SecureToken" default answer ""
set user_entry to the (text returned of the result)
on error number -128
set user_entry to ""
end try
return user_entry
end tell')
done
echo $user_entry
#pass info into terminal to grant token from admin user
sudo /usr/sbin/sysadminctl -secureTokenOn $currentuser -password $user_entry interactive || -adminUser $4 -adminPassword $5
exit 0
This kills my automation. So I will need to do more work to figure out how to automate the token process for users that do not have them.
The other issue with the script is that it logs the standard user's account password to the scrip log. So I will stop using it for security reasons soon. For a middle school student though its not a deal breaker.
My recommendation is for you to verify that your standard users have token volumes. Then try the erase and install workflow again.
I hope that helps! ~B
+4Just wanted to reply to this topic. It now looks like PrivilegesDemoter will revoke admin permissions silently in the background after a specified period of time, regardless of how the permissions were elevated (either by right clicking on the Privileges dock icon or running the app). Settings can also be configured in a Configuration Profile.
I've tested this and it seems to work :)
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.