Honestly, if I were doing it, I'd write something in Apple Script. It can do most of the heaving lifting, and you can bake passwords in but export it as a run-only application and the user/pass should get garbled if they tried to read the files. I've got a few things that leverage our JAMF service account that way that can do things running as admin without sharing the actual credentials. It could be something as simple as
tell application Finder to mount smb://blah as user with password
or you can provide drop downs or lists of choices and get as fancy as you want.
It shouldn't need admin rights to mount a share, if you use Apple Script for example if should run the mount attempt as the current user and only ask for credentials to the share if required, not the local machine.
If you know the shares why not just have them mounted using a policy in Self Service instead? Is there a particular reason to use a 3rd party tool for the drive mounting? You can then using scoping and various other tools to restrict who and where this can occur.
Editshare Connect is a third party app that is baked into their storage equipment.
Designed for media related workflows.
There is a particular way that the Editshare app needs to be packaged so that it doesn't prompt you for credentials when it mounts the drive.
A reboot is also required after the package is installed.
We're about to close up shop for the year so I'll try and give you a hand after the break (if you still need a solution)
Sorry, completely forgot about this.
Ever since Editshare updated their app, we've had even more trouble with permissions.
It's a real pain in the ass.
They've changed something in the startup script and it's now randomly prompting for admin credentials for ALL accounts.
Previously, authenticating the one time would get rid of the prompts for everyone, but now it pops up randomly even after being authenticated already.
The current workaround is to allow password-less root access to the EditShare app for all Active Directory accounts.
Not ideal, but not really much choice until they do something about it.
This is the line I've added to the sudoers.d file:
"%ADSROOTDomain Users ALL=(root) NOPASSWD:/Applications/EditShare Connect.app/Contents/MacOS/Editshare Connect *"
Then I wrapped the the command to sudo open the above file into an app, and hid the original EditShare Connect.app so no one gets confused trying to figure out which app to use.
It's messy, but it works for now.
We'll need to change the workflow eventually but it's on the back burner for now.
Also, from v220.127.116.11 the EditShare Client now comes as a pkg so that's one less step you have to take.