Clearly one must provide either an administrator username and password for pre-High Sierra or the password of an account which has a Secure Token for High Sierra and later in order to authorise FileVault related tasks. This script therefore displays a dialog box asking the currently logged in user to authorise the process.
It is also the case that either the jamfmanager account may not have a secure token, or even if it does there is no way for a script to access the password for the jamfmanager account.
However it is potentially possible for JSS to 'know' the password for a local admin account on the client Mac. This might be because all client Macs have the same local admin account and password, or as in my case because I am using the LAPS scripts to manage random passwords for the local admin account in JSS. (See - https://github.com/unl/LAPSforMac )
It should therefore be possible to either use the same known local admin username/password or better still the LAPS managed local admin password and pass this as a parameter to a modified version of this script. It would then be possible for this modified version of the script to run completely invisibly to the user without the need to display a dialog asking for a password. I think most people would agree this is a highly desirable goal.
As such could the author add the option to pass parameters for a local admin user name and local admin password. If these parameters are empty then the script could operate as now and display the dialog, if the parameters are provided then it should try using them without the need to display the dialog.
Note: Whilst passing a fixed universal username and password as parameters is easy enough, is it possible to pass as a parameter the value of an extension attribute for the individual client Mac the script is going to run on? I think this should be possible although as the LAPS scripts after all set the extension attribute, but it maybe that you cannot pass it to the script as a parameter and instead the script i.e. this script, would need to read the extension attribute directly. The method for doing this should be basically the same as the LAPS script but in reverse.
Clearly one must provide either an administrator username and password for pre-High Sierra or the password of an account which has a Secure Token for High Sierra and later in order to authorise FileVault related tasks. This script therefore displays a dialog box asking the currently logged in user to authorise the process.
It is also the case that either the jamfmanager account may not have a secure token, or even if it does there is no way for a script to access the password for the jamfmanager account.
However it is potentially possible for JSS to 'know' the password for a local admin account on the client Mac. This might be because all client Macs have the same local admin account and password, or as in my case because I am using the LAPS scripts to manage random passwords for the local admin account in JSS. (See - https://github.com/unl/LAPSforMac )
It should therefore be possible to either use the same known local admin username/password or better still the LAPS managed local admin password and pass this as a parameter to a modified version of this script. It would then be possible for this modified version of the script to run completely invisibly to the user without the need to display a dialog asking for a password. I think most people would agree this is a highly desirable goal.
As such could the author add the option to pass parameters for a local admin user name and local admin password. If these parameters are empty then the script could operate as now and display the dialog, if the parameters are provided then it should try using them without the need to display the dialog.
Note: Whilst passing a fixed universal username and password as parameters is easy enough, is it possible to pass as a parameter the value of an extension attribute for the individual client Mac the script is going to run on? I think this should be possible although as the LAPS scripts after all set the extension attribute, but it maybe that you cannot pass it to the script as a parameter and instead the script i.e. this script, would need to read the extension attribute directly. The method for doing this should be basically the same as the LAPS script but in reverse.