Pulse Secure 5.2.5 (Build 869) Deployment with Pulse Secure App Launcher

sepiemoini
Contributor III
Contributor III

Greetings, all! In the past, I've used Composer to package Pulse Secure releases which would also contain the necessary connection profiles built-in. I am now in need of deploying Pulse Secure App Launcher to each macOS device for an upcoming MFA-related project. I looked in /Library/Application Support/Pulse Secure/Pulse/ and found the following files.

ed640668b65841b8be610e0f1da96211

Since users will already have a working instance of Pulse Secure, there's no need to push more over the network and have the same version re-installed. I would instead just like to modify their connection profiles and wipe these clean or simply include one specific one needed going forward. What are some of your thoughts on the various approaches that could be used here?

2 ACCEPTED SOLUTIONS

sepiemoini
Contributor III
Contributor III

I think I've figured this out! I created two DMG files using Composer: one without any connection profiles and another with a new connection profile. Using a test virtual machine, I deployed a current build of Pulse Secure 5.2.5 (Build 869) which has two connection profiles.

Test #1: Two Connection Profiles

Step 1. To verify that the installation was successful, I loaded the LaunchDaemon, opened the Pulse Secure.app and confirmed that the two packaged connection profiles were present.

sudo launchctl load /Library/LaunchDaemons/net.pulsesecure.AccessService.plist
sudo open -a /Applications/Pulse Secure.app/

Test #2: No Connection Profiles

Step 1. Once the initial installation with two connection profiles was verified, I opened the Pulse Secure Client-No Profiles.dmg, copied the files in the ~/Library/Application Support/Pulse Secure/Pulse/ directory and copied them to the corresponding location, locally, overwriting the existing files.

ca94e82523664e05b2e33386cc537f1c
9702eba6e29c44c7afc78a37e3e7cc5d

Step 2. To verify that the copying was successful, I unloaded and then re-loaded the LaunchDaemon, opened the Pulse Secure.app and confirmed that the two packaged connection profiles were present.

sudo launchctl unload /Library/LaunchDaemons/net.pulsesecure.AccessService.plist
sudo launchctl load /Library/LaunchDaemons/net.pulsesecure.AccessService.plist
sudo open -a /Applications/Pulse Secure.app/

Test #3: New Connection Profiles

Same as above in Test #2 but referencing the Pulse Secure Client-New RA Profile.dmg containing the new connection profile.

ae9dbd6665f74b4ead23d172a13bccf1

Since these above steps simply deal with local, non-Jamf based deployments, I will report back with a scalable enterprise solution using Jamf Pro :)

View solution in original post

sepiemoini
Contributor III
Contributor III

Eh, so things changed on my end and while we ended up going with no stored connection profiles (users populate this themselves through a web-interface) stored with the deployment, the packaging of the profile using Composer worked the best. The aforementioned script of unloading and loading the LaucnhDaemon was also key if anyone is looking to implement this within their own environments.

View solution in original post

14 REPLIES 14

sepiemoini
Contributor III
Contributor III

I think I've figured this out! I created two DMG files using Composer: one without any connection profiles and another with a new connection profile. Using a test virtual machine, I deployed a current build of Pulse Secure 5.2.5 (Build 869) which has two connection profiles.

Test #1: Two Connection Profiles

Step 1. To verify that the installation was successful, I loaded the LaunchDaemon, opened the Pulse Secure.app and confirmed that the two packaged connection profiles were present.

sudo launchctl load /Library/LaunchDaemons/net.pulsesecure.AccessService.plist
sudo open -a /Applications/Pulse Secure.app/

Test #2: No Connection Profiles

Step 1. Once the initial installation with two connection profiles was verified, I opened the Pulse Secure Client-No Profiles.dmg, copied the files in the ~/Library/Application Support/Pulse Secure/Pulse/ directory and copied them to the corresponding location, locally, overwriting the existing files.

ca94e82523664e05b2e33386cc537f1c
9702eba6e29c44c7afc78a37e3e7cc5d

Step 2. To verify that the copying was successful, I unloaded and then re-loaded the LaunchDaemon, opened the Pulse Secure.app and confirmed that the two packaged connection profiles were present.

sudo launchctl unload /Library/LaunchDaemons/net.pulsesecure.AccessService.plist
sudo launchctl load /Library/LaunchDaemons/net.pulsesecure.AccessService.plist
sudo open -a /Applications/Pulse Secure.app/

Test #3: New Connection Profiles

Same as above in Test #2 but referencing the Pulse Secure Client-New RA Profile.dmg containing the new connection profile.

ae9dbd6665f74b4ead23d172a13bccf1

Since these above steps simply deal with local, non-Jamf based deployments, I will report back with a scalable enterprise solution using Jamf Pro :)

ndeal
New Contributor III

I've tried to copy those connection files on Windows for Pulse Secure and ran into problems with the pulse secure client creating a machine-based guid within the connection settings. What ended up happening was that when multiple users received laptops with the common connection files, users would find themselves being bumped off of VPN continually because the VPN controller was seeing it as multiple instances of the same machine, or something like that. Something to keep an eye out for since it may work the same way for Macs... the connection files are very similar between the two, comparing them side by side.

sepiemoini
Contributor III
Contributor III

@ndeal Agreed! I will be testing this thoroughly with some folks before an enterprise-wide deployment.

I've added a script (see below, nothing fancy) that handles the unloading, loading and opening of Pulse Secure after the DMG and App Launcher packages have been installed. Here's a screen capture of the policy as it stands in our Jamf Pro instance.

42f4e17b2d44472ebea23c77f0f5f1c2

#!/bin/sh

launchctl unload /Library/LaunchDaemons/net.pulsesecure.AccessService.plist 
launchctl load /Library/LaunchDaemons/net.pulsesecure.AccessService.plist 
open -a /Applications/Pulse Secure.app/
open -a "/Library/Application Support/Pulse Secure/PulseApplicationLauncher.app"

exit 0

ndeal
New Contributor III

Nice. Do you mind if I ask what MFA solution you're implementing/testing?

sepiemoini
Contributor III
Contributor III

@ndeal Unfortunately, I am unable to disclose that! In terms of the above workflow, the MFA that we're going with doesn't really impact the system administration side of things. Our infrastructure folks are handling the majority of the MFA piece :)

ndeal
New Contributor III

Got it, no worries!

Chris
Valued Contributor

Have you seen this thread?
Using "jamcommand" to import your connections might be a cleaner solution to this

sepiemoini
Contributor III
Contributor III

@Chris Thanks for the link! I did read over that but don't have a .jnprpreconfig file to work off of. After combing through the provided thread, it appears that it is just a basic text file with the connection profile details used by an organization. Would you (or anyone else, really!) be willing to share a sample of what this .jnprpreconfig looks like?

mrben
New Contributor III

We currently use an AutoPKG recipe to build a payload-free Pulse Secure installer. The pkg-wrapped DMG that you download from the licensing center is unpacked, added to a package root and the following postinstall script runs:

#!/bin/bash

# Install Pulse Secure

/usr/sbin/installer -dumplog -verbose -pkg PulseSecure.pkg -target /

#
# Applying VPN configuration file

"/Applications/Pulse Secure.app/Contents/Plugins/JamUI/jamCommand" -ImportFile "vpn.pulsepreconfig"

exit 0

Here is the jnprconfig we use. I believe some of the variables came from a jnpr export on the MAG and/or a generated conn.dat file on a test box. Hope this helps.

schema version {
    version: "1"
}

machine settings {
    version: "8"
    guid: "aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"
    connection-source: "preconfig"
    server-id: "AAAAAAAAAAAAAAAAA"
}

ive "aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa" {
    friendly-name: "VPN"
    version: "5"
    guid: "aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"
    server-id: "AAAAAAAAAAAAAAAAA"
    connection-source: "preconfig"
    factory-default: "true"
    uri: "https://vpn.domain.net"
    connection-identity: "user"
    connection-policy: "manual"
}

sepiemoini
Contributor III
Contributor III

Awesome, thanks @mrben! I believe the connstore.dat file located in the /Library/Application Support/Pulse Secure/Pulse/ directory needs to be modified and then the launch daemon unloaded/re-loaded. This appears to work fine on my test box (virtual machine) but I am curious what effect this would have on a larger deployment. Obviously, I'll test this myself before a production scaled deployment but I was wondering what your experience has been with populating that connstore.dat with default values. I did notice that when the launch daemon is re-loaded, that those values in the .dat file become machine-specific and are no longer defaults originally specified in the the below section. So perhaps the concern over the generic default values is a non-issue. Wondering what your thoughts are on this.

schema version {
    version: "1"
}

machine settings {
    version: "23"
    guid: "aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"
    connection-source: "preconfig"
    server-id: "AAAAAAAAAAAAAAAAA"
}

ive "aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa" {
    friendly-name: "<ProfileName>"
    version: "12"
    guid: "aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"
    server-id: "AAAAAAAAAAAAAAAAA"
    connection-source: "preconfig"
    factory-default: "true"
    uri: "<CompanyLink>"
    connection-identity: "user"
    connection-policy: "manual"
}

FWIW the friendly-name and uri fields are the two that are specific to our organization and the ones that have, in turn, been modified to work in our environment.

sepiemoini
Contributor III
Contributor III

Eh, so things changed on my end and while we ended up going with no stored connection profiles (users populate this themselves through a web-interface) stored with the deployment, the packaging of the profile using Composer worked the best. The aforementioned script of unloading and loading the LaucnhDaemon was also key if anyone is looking to implement this within their own environments.

macgecko2
New Contributor

Question is it possible to import a jnprconfig that lists multiple urls? I have success with one but not two.

rastogisagar123
Contributor II

@sepiemoini DNS Enries are overriding or not coming to client mac machine when connecting to pulse secure
Posted: Less than a minute ago by rastogisagar
It seems when we are trying to connect Pulse Secure VPN to JAMF Enrolled MACBOOK , there we are not getting DNS server entries, we checked in local client machine DNS entries where we can see local ISP provided DNS server enrtries . Any idea why its overriding or do Pulse secure need to do something. Right now I have just push Pulse secure agent via jamf policy. Do i need to so something more

Sagar Rastogi

rastogisagar123
Contributor II

@ndeal our pulse secure have to do the configurations for pulse secure VPN be compliant to JAMF MDM.

They are asking for server url and viewer url. I know about server url but i am not aware about viewer url. Any idea please

Sagar Rastogi