Junos Pulse 3.0 installation on Mac

[achand]

Has anyone deployed the Junos Pulse Installer through JAMF? It's a simple installer package, but we can't get it to work without requiring the user to reboot? We have to do a load of a LaunchAgent in the users context. The funny thing is, the script works fine when we manually run a trigger to install it, but if the same script is ran on the every15 trigger, it requires the user to reboot for it work properly. I am not sure why that is. Here is the specific segment of code. Any ideas as to why this doesn't work properly when ran on the every15 trigger vs working properly when ran with a manual trigger?

####### This part gets the current user and loads the launch agent as the current user. #
currentUser=stat -f%Su /dev/console
#

######
userPID=ps -ef | grep "loginwindow console" | grep -v grep | awk '{print $2}'
launchctl bsexec $userPID su $currentUser -c 'launchctl load -F /Library/LaunchAgents/net.juniper.pulsetray.plist'

[sgrall-pfg]

There is a version 4.0R1 out that deploys fine as-is, without any additional scripts. I'd contact Juniper support and see if you can get it.

[bbass]

We struggled with the same thing at my company. Eventually, we were able to put together an installer script for the v3.x client. The outline of the procedure was this:

- Create a package with the stock junos.pkg, an installer script, and the junos pre-config file.
- Install that package to /Users/Shared/
- Call the installer script with the "run command" setting in Advanced.

As for the installer script, it did this:

- called /usr/sbin/installer to install the junos.pkg
- opened the Junos Pulse Tray (menu icon) via /usr/bin/open
- opened and hid the Junos Pulse app via /usr/bin/open and some applescript
- imported the Junos pre-config file
- quit the Junos Pulse app
- re-opened and hid the Junos Pulse app
- quit the Junos Pulse app

If it sounds convoluted that's because it is. We found that the application would not work properly until it was launched a second time and quit. For some reason that would get the settings to stick as well as allow for subsequent connections to the Junos Pulse endpoint.

I can post the script if you'd like but I'd also advise to upgrade to the v4 client as none of this is necessary with it.

[achand]

Thanks guys. Bbas could you please post the code? I will check with Junos for a v4 version of the client.

[bbass]

#!/bin/sh

# Change working directory
cd /Users/Shared/Junos/

# Install Junos Pulse software
/usr/sbin/installer -pkg JunosPulse.mpkg -target /
sleep 1

/bin/chmod +x /Applications/Junos Pulse.app/Contents/Plugins/JamUI/PulseTray.app/Contents/MacOS/PulseTray
/bin/chmod +x /Applications/Junos Pulse.app/Contents/MacOS/Junos Pulse
/bin/chmod +x /Applications/Junos Pulse.app/Contents/Plugins/JamUI/jamCommand

# Launch the Pulse Tray
/usr/bin/open -a '/Applications/Junos Pulse.app/Contents/Plugins/JamUI/PulseTray.app/Contents/MacOS/PulseTray'
sleep 1

# Open Junos Pulse in the background and then hide the app
/usr/bin/open --background -a '/Applications/Junos Pulse.app/Contents/MacOS/Junos Pulse'
/usr/bin/osascript -e 'tell application "System Events" to set visible of application process "Junos Pulse" to false'
sleep 1 

# Import the company VPN settings
/Applications/Junos Pulse.app/Contents/Plugins/JamUI/jamCommand -importFile Company_VPN_Servers.jnprpreconfig 
sleep 1

# Quit  the Junos Pulse app
/usr/bin/osascript -e 'tell application "Junos Pulse" to quit'
sleep 2

# Open Junos Pulse in the background a second time and then hide the app
/usr/bin/open --background -a '/Applications/Junos Pulse.app/Contents/MacOS/Junos Pulse'
/usr/bin/osascript -e 'tell application "System Events" to set visible of application process "Junos Pulse" to false'
sleep 5

# Quit  the Junos Pulse app
/usr/bin/osascript -e 'tell application "Junos Pulse" to quit'

exit 0

To be clear, we found that the application had to be opened twice before connecting to a VPN server in order for everything to work in subsequent connections. Hence, the second open/close combination.

Hope this helps.

[achand]

Thanks bbass. I'll give it a shot.

[achand]

Have you guys had any issues with the 4.0r1 client? Our network team is iffy with installing a beta client.

[sgrall-pfg]

As far as I know, 4.0R1 is a final release, not a beta. Our chief of IT security sent it to me, and he isn't a fan of betas either.

I haven't seen any issues, and I spent hours using it myself. Our environment isn't in production yet, so I'm currently the only Mac user testing this version at our company.

[bbass]

We are also not in production just yet but we have several people testing it. No issues have been reported. The holdup for us is the management of the server portion.

Their naming scheme could be better. We upgraded the SSL VPN endpoints to their most recent version within the last couple of weeks and this is the client that is bundled. Also, nothing in the documentation suggests that this is beta:

http://www.juniper.net/techpubs/en_US/junos-pulse4.0/information-products/pathway-pages/junos-pulse-client-install-upgrade.html#troubleshooting

[hkim]

I used a snapshot method to create a custom installer for Junos Pulse 3.1 using Composer. I also modifying it to make sure it got rid of the Uninstall LaunchAgent. I could not for the life of me get the installer to understand the pre config package properly or set the settings I wanted.

It's nice to hear that it sounds like the 4.0 client installer is much better.

[bbass]

We could never get a snapshot created package to work without needing a reboot. Also, different means of installing the Junos pkg - Casper Remote vs every15 trigger vs manual install - would produce different results. It was maddening. Hence, the admittedly weird scripting solution. It took a while to get that all settled. Naturally, they released version 4 just a few weeks later.

We have had no troubles since then. Although, truth be told, I would love to have some command line control of the client. Seemingly the only CLI capability it has is to import the server pre-config file. It would be great to be able to start/stop connections like you can with Junos clients on other platforms.

[hkim]

Just wanted to add to this discussion with some news. Repackinging through snap shots on the Junos Pulse requires that the connstore.dat stored in /Library/Application Support/Juniper Networks/Junos Pulse/ be edited. If you don't you'll see this behavior in your environment.

http://kb.juniper.net/InfoCenter/index?page=content&id=KB25581

The script they give does not work as written, but you can either distribute the "fixed" file, or use this script.

#!/bin/sh # stop pulse access service # remove local guid from connstore.dat # restart service PLIST='/Library/LaunchDaemons/net.juniper.AccessService.plist' CONNSTORE='/Library/Application Support/Juniper Networks/Junos Pulse/connstore.dat' sudo launchctl unload $PLIST sudo sed -i .bak '/machine "local"/{n;d;}' "$CONNSTORE" sudo launchctl load $PLIST

[strangeluck]

Hey bbass, thanks for the script you posted above. We're about to begin deployment of the Pulse app in our environment and I was going mad trying to get consistent results from the initial script I put together. You just saved me a day of troubleshooting to get this package working properly. Makes no sense to me why Juniper requires you to launch the app twice, but for whatever reason, that fixed the issues we were having. So thanks for posting.

[jhbush]

We are installing version 4 using the standard installer available from the device and then telling the app to configure itself with a .jnprpreconfig file. This works very well for us and we deliver 3 different settings: Domain credentials, Two Factor Token, and Two Factor Certificate. Postflight script below:

#!/bin/bash

/usr/sbin/installer -pkg /private/tmp/JunosPulse.mpkg -target /

if [ -d /Applications/Junos Pulse.app ] ; then

/Applications/Junos Pulse.app/Contents/Plugins/JamUI/jamCommand -importFile /private/tmp/Mac.jnprpreconfig

    echo "Pulse Client Installed"

else 

    echo "Pulse Client Not Installed"

fi

exit 0

[bbass]

Our experience has been much better with the v4 client. None of the silliness that was necessary with the v3 client is needed anymore. It almost acts normally! The only caveat is to make sure you are using the latest version. Many Mac bugs were fixed in the last update.

[jonb]

Not sure if this is the right place for this - I'm struggling to find an answer to my problem.

I had Junos Pulse (3.x) fall over running on MacOS 10.8.5 and stupidly tried to reinstall it over the existing version. The installer got to the end and warned my that it was going to *remove* the existing configuration and was this okay.....I said no. The installer then proceeded to uninstall Junos Pulse. I have now got myself in limbo, where no matter how I answer this question the installer always removes Junos Pulse as the last part of its installation! I guess there is a flag that's been set that is say there waiting to trigger uninstallation, and it's not getting reset during the installation.....

Either way it's a bit weird that the installation package didn't check for a pre-existing installation when I originally installed over the top, and weird that it does the uninstallation at the end.

Not sure how to proceed with this. My workplace isn't distributing an updated Pulse, so I'm stuck with trying to fix 3.1. Any suggestions would be much appreciated.

Cheers, Jon

[gachowski]

Jonathan,

I have not see your issue but I would,

Check the LaunchAgents and LaunchDaemons folders for juniper files.

You can re add the/a configuration file with

/Applications/Junos Pulse.app/Contents/Plugins/JamUI/jamCommand -importfile location to the .jnprpreconfig file

If pulse is on the mac you can also you can get it to auto install and you should not see the message if you change any file inside the Pulse.app there is LaunchDaemon "net.juniper.UninstallPulse.plist" that should cause Pulse to uninstall itself. Kinda a bug in 3.X builds.

C

[kellerapps]

Currently using OpenVPN which doesn't have posture check. Does the Pulse posture check work well? Thx.

[JPDyson]

@kellerapps This is second-hand (previous conversation with our Juniper admin), but it's not that great. I think it's only able to check the presence of a process or file, so checking the status of more subtle implements (such as FileVault 2) require you to generate tag files with Casper policies, and then have the Host Checker look for those tags. If it were able to interact with the shell, that would be ideal. Lacking that, YOU do the posture checking with Casper, and tell the Host Checker with tag files.

Worth noting: the only other posture checker we use also works the same way. Not entirely useless, just means we have policies to add/remove tags based on more thorough checks where required.

[workdayitadmin]

We user Casper Composer and create a package that creates a folder called:

/Users/Shared/Software_Temp/

We create a package that contains the Junos Pulse installer that is located in the aforementioned Software_Temp folder along with a Junos Pulse configuration profile.

NOTE: We don't use /tmp because the contents get erased on reboot and we're not performing the post-install process inside the pkg file created with Composer.

After the package has been deployed and the system reboots from NetBoot, the post-install script gets kicked off. The script performs the following tasks:

sudo installer -verboseR -pkg /Users/Shared/Software_Temp/Junos Pulse/JunosPulse_3.1r5.0_b34907.mpkg -target /

/Applications/Junos Pulse.app/Contents/Plugins/JamUI/jamCommand -importFile /Users/Shared/Software_Temp/Junos Pulse/Configuration/Default.jnprpreconfig

NOTE: The sudo command is not required, I just use it here so it's easy to identify which commands require escalation. JSS ignores it.

The post-install does some house-keeping and removes the Software_Temp folder and all it's contents.

That's a wrap.