Skip to content

05 Compliance Policies

Ayla Abbott edited this page Feb 16, 2020 · 2 revisions

Compliance and your users

Some of the biggest questions I get are:

  • How do we make the user do this?
  • Can we force this to happen?
  • What if the user ignores this?
  • How is your tool sure to make sure things happen?

The Answer: Compliance Policies

For this I've created a new UEX Check called compliance. This should be used SPARINGLY.

The Philosophy

Personally I'm of the belief that if you enable your user to update software easily and as painless as possible then this shouldn't be a problem. This does not convince most IT Security Departments. For that reason I want to give you some guidelines.

Guidelines on how not to piss off people with "Compliance"

  1. Only use the compliance check if there is an actual IT Security Demand that requires it.
  2. Give the user time to do it on their own without compliance enabled first.
  3. Always enable the updates in your Self Service
  4. Communicate ahead of time that something is being pushed that is required for Security Reasons or to patch Important Vulnerabilities or that Will make your Mac even MORE secure

How to use it?

If you have a policy for an application or update or script... whatever!...that requires it to be forced for 'Compliance' reasons then all you have to do is add the Check Compliance to the $5/checks parameter.

When does it happen?

  • If the user has run out of postponements/deferrals according to your Maximum Deferral Limitation

AND

  • They ignored the UEX window 3 or more times

AND

  • The checks has compliance set

What Happens?

  • Then a window appears in bottom right window for up to 5 minutes that the policy is running automatically
    • You can set the name of your team at the top of the interaction script so it's signed by Service Desk or Your operations team, or if you're feeling brave then you can put your own name/email/phone number.
    • This is found in the jamfOpsTeamName variable.

This $action is required for compliance and security reasons. As it has been put off beyond the limit, this will now be installed automatically.

In the future, to avoid forceful interruptions please try to run this $action before you run out of postponements.

Thank you, $jamfOpsTeamName

  • All the predefined actions will then happen
    • Apps will be Quit
    • Apps will be Blocked
    • The user will be logged out at the end after the countdown in the 00-uexlogoutagent-jss
    • The computer will restart at the end after the countdown in the 00-uexrestartagent-jss

New Feature - switching from a standard to a compliance policy

As of v4.2.1 there is a new default behavior for the sake of the user:

  • When the UEX script runs, if the policy is a compliance policy AND
    • there is a deferral already for this policy
      • but the last deferral was not with the compliance check enabled
      • reset the deferral number to zero

This is setup just in case you have rolled out a deployment without the deployment feature and user's have exhausted their deferrals then they won't be forced into it the very next time. I'd recommend using compliance from the get-go only for those security updates and OS deployments. Also use your internal commutations processes to inform users in advance.

One Exception

  • If Power is required then it will loop around and wait for the user the plug in power
  • If they do not have power available they can select that button and the postpone will be set for one hour.