You could use an app called Platypus - this allows you to wrap shell scripts into an app that can then be run at login via MCX, Profile etc. I've used it in the past for this exact reason and it's never failed me.

@EduMac89 Thanks, you know I've heard of Platypus but didn't even come to mind for this.

You could look at Platypus for this as suggested. It does a pretty good job of hiding the script contents in a way that only someone who really understands what they are doing could possibly obtain the script contents.
Platypus apps can be made more or less invisible if you choose not to give them any GUI elements and also make sure the app doesn't show up in the Dock when its launched. It might be a good option for this.

A couple other suggestions you may want to consider to help curb users exploring your LaunchAgents

• Name them as generically as you can, while still having some meaning to you. Try not to make the naming of the plist so obvious as to what it does or what its for.


• Make the actual plist files invisible when deployed by using the following code on them - /usr/bin/chflags hidden /Library/LaunchAgents/com.org.name.plist

The last command will make it invisible when they open the /Library/LaunchAgents/ directory in Finder, though they'd still be able to see if they do something like ls -al /Library/LaunchAgents/

@mm2270 Wow, Thanks for the info! This is exactly what I was looking for. We restrict terminal access so users won't have the chance to do an ls -al on the directory.

Another option is to use a login policy in Casper that runs a script. The script that runs can use echo commands to build a launch agent as well as the script that you want the launch agent to trigger. This script that gets created can include a line to remove the launch agent. Basically what you end up with here is a launch agent and related script that's controlled by your JSS. Its invisible to the end user because after it runs it no longer exists.

If you want a sample of what I'm talking about let me know.

@cbrewer
that is brilliant!!. Please post a sanitized sample if you can

@LSinNY Just wrote a long reply and it failed to post so here we go again...

Below is a sample from a script I use to launch ADPassMon on a user's login. For this to work I think you need ManagementFramework Check-In set to NOT "Perform login hook actions in background".

The script will build a temp script in /private/var/tmp. The temp script in my case just has a line to open the ADPassMon app. It also has lines to remove the temp script itself as well as the launch agent.

#Script to launch ADPassMon and remove LaunchAgent

echo "open /Applications/ADPassMon.app/" >> /private/var/tmp/Activate_ADPassMon.sh

echo "rm /Users/$3/Library/LaunchAgents/ORG.ADPassMon.plist" >> /private/var/tmp/Activate_ADPassMon.sh

echo "rm /private/var/tmp/Activate_ADPassMon.sh" >> /private/var/tmp/Activate_ADPassMon.sh

chown $3 /private/var/tmp/Activate_ADPassMon.sh

chmod 755 /private/var/tmp/Activate_ADPassMon.sh



#Check for existing launch agent

if [ -f /Users/$3/Library/LaunchAgents/ORG.ADPassMon.plist ]; then

    echo "LaunchAgent for ADPassMon already exists. Removing..."

    rm /Users/$3/Library/LaunchAgents/ORG.ADPassMon.plist

fi



#Write LaunchAgent to launch ADPassMon on login

defaults write /Users/$3/Library/LaunchAgents/ORG.ADPassMon.plist Label ORG.ADPassMon

defaults write /Users/$3/Library/LaunchAgents/ORG.ADPassMon.plist ProgramArguments -array

defaults write /Users/$3/Library/LaunchAgents/ORG.ADPassMon.plist RunAtLoad -bool YES

/usr/libexec/PlistBuddy -c "Add ProgramArguments: string /private/var/tmp/Activate_ADPassMon.sh" /Users/$3/Library/LaunchAgents/ORG.ADPassMon.plist

chown -R $3 /Users/$3/Library/LaunchAgents

chmod 644 /Users/$3/Library/LaunchAgents/ORG.ADPassMon.plist

echo "Created LaunchAgent to launch ADPassMon on login"

Another option is to adopt an open and transparent relationship with your users, and abandon "us vs them" IT philosophy

Just sayin