Skip to main content
Question

Limiting policies to Macs currently on our network

  • February 22, 2017
  • 3 replies
  • 44 views
S
Forum|alt.badge.img+6

My JAMF repository is on a file server that can only be reached from our internal network.

If a policy tries to install a package, and the user is working remotely, the policy fails.

I have a possible solution, and would like some feedback.

Since we have a small number of fixed public IP address, I can tell if a computer is checking in from our own network (or not on our network). I'm thinking to create a Smart Group called Macs NOT on our LAN (based on IP address), and for policies that deploy packages, I'll add that Smart Group on the Exclusions tab.

Is that a reasonable approach? Is there a better way?

3 replies

A
Forum|alt.badge.img+8
  • al_platt
  • Contributor
  • February 22, 2017

We use network segments for things like this... if a user is on the VPN segment for example i don't scope any larger packages eg Office.

Seems to work well.

B
Forum|alt.badge.img+26
  • blackholemac
  • Honored Contributor
  • February 22, 2017

Network segments are the way to go. What I do is build the scope as normal but use the limitations tab to limit internal-only policies to defined subnets. In our case we have one or two policies that do need to execute globally so this format gives me the option to write a scope to affect all or write a scope that is limited to internal machines only .

F
Forum|alt.badge.img+1
  • fgant
  • New Contributor
  • February 22, 2017

I just wanted to chime in and and give a little clarification on this. As al_platt and blackholemac said, network segments are definitely the way to go. But, your solution of using smart groups was a creative method.

The problem with the smart group solution, as I understand it, is that the smart group is only updated when inventory updates which is only at certain intervals, every 30 minutes at my organization. But, and again this is how I understand it though I could be wrong, the network segment should be based on where the traffic/request originates from.

The other problem with the smart group solution is with the criteria used in creating it. For the IP Address criteria, you have four choices; is, is not, like, and like not. To get a complete segment, you could use "IP Address LIKE 192.168.1." for example, to get the entire /24 subnet but you're limited from anything more specific. The network segments, on the other hand, allow you to set a range of IPs making it a more elegant solution with much more flexibility.

edit grammar

Terms & ConditionsCookie settingsAccessibility statement