By randomizing the password you prevent the same password from being on all of your devices. Then using policies in Jamf Pro, after the Bootstrap Token has been escrowed to Jamf Pro, you can randomize this account password. The workflow they outlined is to create the PreStage account and the Management Account that is used for User Initiated Enrollment (UIE) with the same password. There’s a better way to handle this with Jamf Connect and just in time provisioning of an admin account, but this workflow is for those that maybe are not using Jamf Connect, yet. You know, times like when you need to install software on a machine, or do some other admin task but don’t have a user account that is admin. One of the workflows that they presented was to utilize the local admin account that is created during a PreStage enrollment as a local admin account for times when you need an admin account. This is helpful if you don’t wish to log into Jamf Pro and check the extension attribute you can utilize Apple Remote Desktop, Jamf Remote, SSH, or of course physically accessing a machine.During JNUC 2022 the GOATs, Mark Buffington and Sean Rabbitt, presented “ One Account to P0wn Them All: How to Move Away from a Shared Admin Account”. …where “username” is the respective user that you wish to know about. Just as an additional note, if you are on a machine and quickly want to check the secure token status of a particular user, go ahead and run this: sudo sysadminctl -secureTokenStatus username You can use an advanced search or smart group to target machines that have no users with secure token enabled. Incorporating this into your Jamf Pro instance can help you identify potential problems with machines ahead of time before you attempt to enable FileVault on them. (If you wanted to hardcode a user name into the script, just replace “$username” with the actual user name you’re wanting to check). read /Users/$username AuthenticationAuthority | grep -i -o -q 'SecureToken' This might be useful if there is some sort of local admin/management account present on all of the machines that you use to grant secure token to other users on the system.Īs far as actually determining secure token status, this is the meat of the script: dscl. …where “serviceaccount” is the account name of your Jamf Pro user, “serviceaccountpassword” is the service account’s password, and “yourjamfproname” is your Jamf Pro server name (unique portion of the URL).Īlso, I suppose if you wanted to hardcode a username, you could do that as well. You can write this very simply and just check the secure token status of the currently logged in user and assign it a variable: username=$( ls -l /dev/console | awk '') First, you need to decide how to determine the username to be checked for secure token status. The same principles apply here in this extension attribute that I showcased previously in my post on changing computer names. If you’re here reading this, I’ll assume you already know that – I can’t imagine you stumbled upon this blog post accidentally. Again, as with the last post, I’m not going to go over what secure token is. In keeping with last week’s post, today I’ll share a little extension attribute I wrote up to collect the status of a respective user’s secure token status.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |