Skip to main content

I have an admin account created with our DEP Profile "Staff admin". We manually create a second admin account "Tech admin" when provisioning and finishing touches for distribution. I want to get rid of that Staff Admin account, both moving forward for newly provisioned devices, and for existing devices in the fleet.

For the first, all I need to do is replace the info in the DEP Profile, is that right?

For existing accounts, how can I achieve this? My concern is with the secure boot tokens and ensuring that Jamf can still perform tasks administratively for both new and existing devices without issue. I don't have a full grasp on how Jamf performs elevated tasks and don't want to screw it up!

Unless I'm missing something I don't see a payload to do this in the documentation. As a scripted solution, any known templates that have been used or might be useful here? Thanks in advance!

The command below looks like it works fine in a test. 

sudo /usr/bin/dscl . -delete "/Users/staffadmin"

 But, this does leave the Home folder and .maybe other data behind. Is there a more comprehensive/best practice for doing this? And, i.f this was the autoadmin created with the DEP profile from Jamf, will that affect anything with Jamf managing the device?

sysadminctl -secureTokenStatus techadmin

Returns that secure token is enabled for this remaining admin account. So, there's still a local admin on the device, and it has secure token. I guess I'm just unsure of what credentials Jamf is working under to perform tasks, how it might affect things to remove the autoadmin account. The devices that I'm working with are all MacOS 10.5 or greater. Should be good with the recent September update to Jamf School allowing escrow of bootstrap tokens?

I can't answer all of your questions, but this might help.

"For the first, all I need to do is replace the info in the DEP Profile, is that right?" - I believe that is correct

We have tried to avoid changing the username, but have had a few instances where we needed to change the passwords.  Really, it probably should be done on a normal basis.  I hope they add local account management to "Configuration Profiles" soon.   

We have successfully used bash scripting via the JAMF School scripting module to add / delete local accounts.  Here is an example of a script we use to update a local account

 

(creates a local admin account if it does not exist or updates it by deleting it and recreating it, also hides it on the login screen)

#!/bin/bash
sudo sysadminctl -deleteUser localadminaccontname
sudo sysadminctl -addUser localadminaccontname -password theaccountpassword
sudo dseditgroup -o edit -a localadminaccontname -t user admin
sudo dscl . -append /Groups/admin GroupMembership localadminaccontname
sudo defaults write /Library/Preferences/com.apple.loginwindow HiddenUsersList -array-add localadminaccontname

I can't answer all of your questions, but this might help.

"For the first, all I need to do is replace the info in the DEP Profile, is that right?" - I believe that is correct

We have tried to avoid changing the username, but have had a few instances where we needed to change the passwords.  Really, it probably should be done on a normal basis.  I hope they add local account management to "Configuration Profiles" soon.   

We have successfully used bash scripting via the JAMF School scripting module to add / delete local accounts.  Here is an example of a script we use to update a local account

 

(creates a local admin account if it does not exist or updates it by deleting it and recreating it, also hides it on the login screen)

#!/bin/bash
sudo sysadminctl -deleteUser localadminaccontname
sudo sysadminctl -addUser localadminaccontname -password theaccountpassword
sudo dseditgroup -o edit -a localadminaccontname -t user admin
sudo dscl . -append /Groups/admin GroupMembership localadminaccontname
sudo defaults write /Library/Preferences/com.apple.loginwindow HiddenUsersList -array-add localadminaccontname


Ty sir, noted and helpful. My big concern was messing up something with secure tokens and Jamf Schools ability to perform administrative tasks, if it was leveraging that admin account to do so.

As I was trying to learn how to manage the local accounts a little better, it looked like dscl is depreciated in favor of sysadminctl, and sysadminctl has the ability to assign/remove/modify tokens where dscl does not. Is that correct? 

Reply


Terms & ConditionsCookie settings