Have you gotten your hands on their Jamf deployment script? That has the logic for specifying the tenant and other variables.

I haven't yet. Think you can point me in that direction?

You will need someone with access to either send you the script from their site, or get yourself access to support.netskope.com.

Looks like their scripts are dependent on being AD bound? We will be using Jamf Connect more than likely in the near future.

No, you don't have to be AD bound. There is a config option to use a profile for "email_from_pref". You would deploy a profile that captures the users email from Jamf using the $email variable, then you specify the location of that variable in the script.

I did our deployment for Netskope. You will need to request for an account from netskope. Once you do that you can get the script and step by step directions to set it up. Below is the link to what I am talking about but you will need to setup an account with them first. Also be aware that the $email will only work once you have their AD connector setup first. It takes a long time for that thing to populate so get with your Netskope installation manager and ask them to get you what you need to get setup.

https://support.netskope.com/hc/en-us/articles/360025614873

@kmathern Did you successfully get their installer to work with the $Email parameter? I configured the profile, script, and policy with their support on the line. I can get it to install with a plist that I create local on my machine, but not with the pushed JAMF plist (I uploaded the same plist I used to install locally). I keep getting back "Email address not valid". The Ad importer has been completed and I checked the console and saw my account showed up.

I'm deploying out v72 to my environment now. However, we are bound to AD and I'm using the "peruserconfig" setting. Everything works smoothly for me.

I'm using the vendor's package setup in a policy with a "before" script that puts in all the tenant information. Then, I have an "after" script that runs and modifies the Uninstaller permission settings and moves the uninstaller to a hidden folder. This is to prevent people from uninstalling it - our users currently have Admin rights.

I found the answer. The Netskope script does not know how to look for com.company.application.plist in the /Library/Managed Preferences. It can only look for application.plist. I have the fix for the script if I want to use the apple naming convention, but want to leave it as Netskope best practices for our deployment. I have asked them to update this to be able to look for com.company.application as it looks cleaner.

@kevin.dixon Mine does work via jamf deployment, but like I said it only worked after I found out we had to have the AD connector installed.

@kevin.dixon I do remember now that you mentioned it, that I worked with their support as well because the params in the script were not getting populated and therefore failing. Netskope support had me just hard code all the variables into the script. They said it's working for us we don't know why it's not working for you. So I will have to change the script itself if I ever need to change it. I don't see that happening so I left it as is.

In the same boat deploying NetSkope client. There appears to be 3 choices: Use installation parameters to tie the agent to a specific user on the local machine via their AD email address This hard-codes the machine agent to the specific user. For multi-user machines this might be an issue when deploying policies.
Use params to enable IDP based enrollment so that user gets prompted to login (this is a one time login per user) If you have multi-user machine this is pretty much the only option Need Azure AD, OKTA, etc as your IDP
Use $email param from JAMF to tie the client to the email address defined in JAMF for the user Require machine to be bound to AD. User account on machine must be the AD account. JAMF must be setup to pull in AD info for the user (AD Connector, JIM, etc).

Have asked for feature enhancement to support Kerberos auth so that you can use info form Enterprise Connect / JAMF connect to automate this task.

@csa

We don't use Enterprise Connect, we use NoMAD, but you should be able to grab the AD UPN information from EC I would think. That's how we got around the Netskope crap script. We changed their script to attempt to pull UPN from the NoMAD plist first, then from AD using their dscl call. If unable to grab the UPN from either we do not attempt the install.

You can also verify if the UPN is accepted by Netskope before attempting install:

curl -s "https://<netskopetenanturl>/api/v1/userconfig?token=0cfe04c4237cc33dc7f383af5ddbe2e3&email="${UPN}"&configtype=agent" | grep success

If that returns successful then you can continue on and install the Netskope agent.

Hi @mlambert

So this broke my heart for the longest time.

1st thing is the machine must have the correct username under the user and location tab in JAMF
Then you deploy a config profile to create a plist which contains the email
{email=$EMAIL}

Then you get the script from Netskope and fill in the variables such as tenant and user the plist to fill the UPN

@taz231190 YEP. not a great process. Also I was never able to get it to install 100% of the time. We were seeing 10% failure rates.

I never got the timing to work with a profile in my enrollment workflow. I had to created the file with the email address at the required location, kinda faking it out.

C

Agreed, would providing option to use signed in username or kerberos id be that much of a hard item for them to support?

Bump!!

Anyone have Netskope working with Big Sur? The docs say 78 should work but I am seeing PPPC notifications????

Thanks

C

@gachowski I'm still waiting for them to respond to my ticket asking for guidance on how to configure for Big Sur. Their documentation is very vague.

@patgmac

Thank you sometimes it's good to know you are not the only one!!! I'll open a ticket too!!

C

If you are trying to get Netskope to deploy without AD joining the Mac (i.e. using preference_email in Parameter 7), note that Netskope's instructions are wrong. In the video that walks you through setting up the policy, script, configuration, etc. it tells you to enter the plist file name without the extension into Parameter 6 when adding the script to the policy, which is the same way you enter the preference domain in the configuration. However, within the policy when defining the name of the plist in Parameter 6 you MUST include the .plist extension. If you don't, the script will exit with an error trying to find the plist file and then deploy Netskope in IDP mode as a fallback. This is the script result:

Script result: Installation is configured with preference_email Param1 / Param2 [COMPUTER NAME] Param3 [USERNAME] All Logged in user names: [USERNAME] Logged in user name: [USERNAME] User name is [USERNAME] length [#] User name is [USERNAME] length [#] Going to remove IdP config file Tenant url is [TENANT].goskope.com restAPIToken is [API_TOKEN] email pref file path /Library/Managed Preferences/template /Library/Managed Preferences/template not found, exiting installation process

As you can see in the script result, it takes the entire value in Parameter 6 and looks for it within Managed Preferences. This is where the plist file you uploaded in the configuration is stored. So by changing the value to template.plist (or whatever you named your plist) will get the script to find the file correctly.

After I changed the value and appended .plist in the script parameters for the policy, it deployed perfectly without us having the AD connector installed. We really didn't want to have to add the AD connector just to deploy Netskope.

I've contacted our organization's Technical Success Manager at Netskope to let them know to update their documentation.

I can confirm that we also specify with the .plist. I don't remember if I read their docs close enough to try without .plist. ;-)
Been using this setting for a while now.

The problem I have, is if the email does not exist in netskope (for various reasons), it falls back to IDP mode and displays a window asking for tenant and can't be closed by the user. I'm trying to get them to fix this before pushing any updates.

@patgmac Are you seeing the prompt when the Netskope tenant doesn't recognize the email, or when no email exists to be written to the .plist in the Managed Preferences folder? The latter was my problem.

My solution to avoid getting the Netskope configuration prompt was to have a Smart Group that checked for a non-Null email address which was used as a Scope Exclusion for our Netskope Configuration Profile. Then an EA was created to verify an email address is present in the .plist created by the Applications & Custom Settings payload of the that profile. A second Smart Group based on that EA is used as the Scope Target for the policy that deploys the Netskope agent. That ensures when the netskope agent is installed something is present for it to use as the configuration email address.

@patgmac their docs are terrible anyway, very thin. They mention towards the end to add the plist, but that's literally the only thing they mention about the plist. They never say one has to be created to begin with or added to a configuration, unless you sit through the 7 minute video where it finally gives you some context. And even then it's annoying that since it's a video you can't copy and paste things like the ID for the KEXT or the example command they give to create the template plist.

Anyway I'm just glad we got it working. It's one of the bigger reasons we switched to Jamf, with regards to endpoint management pain points we had in our specific environment. Now I just need to figure out if we want to use Okta SAML for self-service enrollment or the LDAP interface from Okta. Depends on if SAML populates the email field, which I think LDAP brings over attributes and SAML only brings their username. But in our case username = email, so if we can figure out a way to fill that attribute in we'd stick with SAML.

@GaleForce You can bring in any LDAP attribute as an Extension Attribute. Just create an EA and choose "LDAP Attribute Mapping" from the Input Type popup. After the EA is created you'll see a text field on the EA page listing the LDAP Attribute Variable (e.g. $EXTENSIONATTRIBUTE_104).

Once you have that variable you can use it in a Configuration Profile Applications & Custom Settings payload to write the attribute to your plist. The payload for my com.myorg.netskopeconfig domain has {email=$EXTENSIONATTRIBUTE_104} as the plist data.

has anyone had success getting the new System Extensions for Netskope whitelisted via Config Profile on v78 in Big Sur?