Straight from the Admin’s guide the TL;DR:

LAPS allows you to:
Automatically rotate local administrator passwords

Store local administrator passwords in a secure online location

Audit who has accessed local administrator passwords

In this first phase of the launch, LAPS is available via API only.

So I thought would be fun to poke around to learn a bit more about it by making a Slack slash command to interact with.

No fancy diagram this time but here’s a brief overview of how it all works together:

• a Slack app will make available a slash command

• the command will hit an AWS API gateway

• API gateway invoke a lambda

• Lambda will retrieve the LAPS credentials from Jamf Pro and store them in Secrets Manager for an easy retrieval

This last bit is where I asked myself it it was the best delivery method possible. We have to keep in mind we’re dealing with administrator credentials to our end devices, so we want to store and share them as securely as possible.

An idea could be to integrate a password manager and wire it up to the Lambda via API, but that’s maybe for a future post. For now, we’ll use Secret Manager which provides at rest and in transit encryption with Amazon’s managed KMS.

To start, we need to enable LAPS. For this we can use the /v1/local-admin-password/settings endpoint.

url = f"https://{jamf_url}.jamfcloud.com`/v1/local-admin-password/settings`"
payload = {
 "autoDeployEnabled": true,
 "passwordRotationTime": 3600,
 "autoExpirationTime": 7776000
}

headers = {
 "Authorization": f"Bearer {token}",
 "accept": "application/json",
 "content-type": "application/json"
	 }
	
response = requests.put(url, json=payload, headers=headers)

We can then do a GET request against /v1/local-admin-password/settings to verify LAPS has been enabled correctly.

We can now move on to the AWS side of things. I’ve covered in previous posts how to setup the API gateway + Lambda so we’ll skip that part. The only addition in this case is that we’ll need to give our Lambda IAM user permissions not only to read but also to write to Secrets Manager.

The way Slack sends back to your APIs the payload data is… fun… so I did come up with an extremely inelegant solution to parse out some data:

#Parse the Slack message content
output = f"""{event}"""
data = ast.literal_eval(output)
body_value = data['body']
decoded_body = urllib.parse.unquote(body_value)
query_params = urllib.parse.parse_qs(decoded_body)
 
#Parse extract device Serial Number from Slack
serial_from_slack = query_params.get('text', [None])[0]
user_name = query_params['user_name']
user_name = user_name[0]
user_name = user_name.strip("[]'")

#Parse extract user's details from Slack
user_id = query_params['user_id']
user_id = user_id[0]
user_id = user_id.strip("[]'")

I’m extracting the user who invoked the slash command in Slack so we can then use the Jamf Pro Azure AD API endpoint /v1/cloud-idp/1002/test-user-membership to do some access based checks. In our script we will define an Azure AD group (or multiple) that are allowed to use LAPS. This way we can lock down the use of LAPS to only administrators or whoever is deemed to get access to it.

Unauthorized users will get a message in Slack to inform them they’re not allowed to use LAPS:

A quick video to show how that would look like:

https://youtu.be/Agqbpb1sJGs

When instead the user requesting the LAPS workflow is member of the Azure AD group, and hence authorized:

First we display a message to let the admin know we got the request and are working on it:

Then the Slack bot will send a message to the user with a link to AWS Secrets Manager that will contain the credentials:

Here’s how it will play together:

https://youtu.be/sTPRBWRK0XA

And that’s pretty much it.

The python script for the Lambda is available here: https://github.com/matteo-bolognini/Jamf-Pro/blob/main/scripts/python/laps.py

As a disclaimer, none of this is something production ready and should not be blindly implemented without proper testing.

This is just a first step exploring the capabilities of the newly released LAPS function, I’m curious to see how others would use it and also can’t wait for this to make it to the Jamf Pro UI.

The “over-engineering” post title is actually a comment my colleague Allen made when I showed him this workflow :) So I thought that’d be a great title to show what I’ve been working on.

To start with the usual: what problem are we trying to solve.

When Mac are sent to repair, it is not uncommon for those to get some hardware replace, causing them to come back with the same Serial Number but a different UDID. Those devices are usually wiped before being sent to repair, so they will need to be re-enrolled in Jamf Pro. If the previous device record haven’t been deleted, Jamf Pro will create a new record for this device enrolling as it’s de-facto a “new” device given it has a new UDID, but it has also the same Serial Number as the old record… and this can lead to some issue.

Lets get right into it with a graph to show what’s the idea to overcome this issue (and to understand the “over-engineering” bit):

Breaking it down it looks more or less like:

• Device come back from repair and is enrolled in Jamf Pro.

• A webhook on DeviceAdded trigger is fired off by Jamf Pro to AWS api gateway which then post the json content of the webhook to a Lambda.

• Lambda will process the webhook, check if a duplicate record of this device exist and if yes, will post a message to Slack, giving the details of the 2 device records and an option to delete the old one

• When an admin pick the “delete” button in Slack, a payload is sent to another AWS api gateway which invokes another Lambda which will parse the admin’s choice

• An API call is made to Jamf Pro to delete the device record.

Lets analyze the first Lambda, which is written in Python. On the webhook we get from Jamf Pro, we will have the SerialNumber and UDID of the device that has just enrolled. We need then to check in Jamf Pro if another record exist with that same SerialNumber. The Classic API (CAPI) is designed to return only 1 results, but here come to rescue the Jamf Pro API (JPAPI) which offers a nice RSQL filter which will return multiple results (if exist) for the given SerialNumber:

https://{jamf_url}.jamfcloud.com/api/v1/computers-inventory?section=HARDWARE&page=0&page-size=100&filter=hardware.serialNumber%3D%3D%22{serial_number}%22%22

Once we have data back from this endpoint, we can easily grab the JSS_ID (device identifier) and UDID out of the json blob:

id_multiple = list(map(int, id_multiple))
 id_multiple.sort()
 
 id1 = id_multiple[0]
 id2 = id_multiple[1]
 
 udid_multiple = []
 for result in output["results"]:
 udid = result["udid"]
 udid_multiple.append(udid)
 print(f"UDIDs : {udid_multiple}")
 
 udid_multiple.sort()
 
 udid1 = udid_multiple[0]
 udid2 = udid_multiple[1]

And that’s pretty much if for the first function, we will just use slack.com/api/chat.postMessage to post the message into Slack, which will look like this:

The next part of the job is to actually capture the user’s input from Slack.

This is done with a pretty simple HTTP response where Slack will post a payload when a user will click any menu item button, and will be sent to our api gateway which will then pass the json blob to the Lambda to be worked on. I have to admit I struggled a bit with Slack formatting of the payload and came up with the (incredibly in-elegant) code below to parse:

request_body = event["body"]
request_body_parsed = request_body.replace('payload=','', 1)
request_body_parsed = urllib.parse.unquote(request_body_parsed)
request_body_parsed = json.loads(request_body_parsed)
 
device_id = request_body_parsed["actions"][0]["value"]
serial_number = request_body_parsed["actions"][0]["name"]
udid = request_body_parsed["callback_id"]
username = request_body_parsed["user"]["name"]

So we now have the device SerialNumber, the “original” ID and the UDID, we can go ahead and delete.

I thought it would be nice to add some little validation of which user can actually delete the device record. Given it’s a no-going-back operation, we might want to restrict that to specific users only, even if you’re posting those alerts in private Slack channels.

JPAPI come to rescue again as we can leverage the Cloud IdP integration (AzureAD, Google LDAP) to actually check if the user who clicked the button is member of an LDAP group or not:

url = f"https://{jamf_url}.jamfcloud.com/api/v1/cloud-idp/1001/test-user-membership"
 payload = {
 "username": f"{username}",
 "groupname": f"{control_group}"
 }

The control_group is a variable we can define in our script which will be an actual LDAP group we will check the user’s membership against.

If the user is not member of the group, they will get a message advising them they’re not allowed to perform the delete operation from Slack:

return {
 'statusCode': 200,
 'body': (f"Account:{username} attempted to delete the device record:{device_id} but is not authorized due to lack of permissions, contact your Jamf Pro administrator.")
 }

This is how it looks like in Slack:

Otherwise, if the user is member of the LDAP group, they will be allowed to proceed with the deletion and a message in Slack will confirm the success of the operation:

url = f"https://{jamf_url}.jamfcloud.com/JSSResource/computers/id/{device_id}"
 headers = {"Authorization": f"Bearer {token}", "Accept": "application/json"}
 response = requests.delete(url, headers=headers)
 print(f"Status Code: {response.status_code}")
 print("Old device record successfully deleted from Jamf Pro")
 
 return {
 'statusCode': 200,
 'body': (f"A device record has been deleted via Slack integration, details as following:\n\nDevice Record ID {device_id}\n\nDuplicate Serial Number: {serial_number}\nUDID:{udid}\n\nDeleted from Jamf Pro by user: {username}")
 }
 

This is how it looks like in Slack:

Time to see a demo:

https://www.youtube.com/embed/7nMBHHW7jcs

The python scripts for the lambdas are available on my GitHub:

https://github.com/matteo-bolognini/AWS-Projects/blob/main/webhook-processor.py https://github.com/matteo-bolognini/AWS-Projects/blob/main/slack_responder.py

That’s a wrap! Hope you enjoyed this journey into over-engineering simple tasks :)

• SAML 2.0 is XML based and in it’s current version has been around since 2004
• OIDC (OpenID Connect) is a newer protocol based on OAuth 2.0 framework and JWT based.

Jamf provides documentation on how to setup the Single Sign On integration with Protect and Azure AD, by default using OIDC: https://learn.jamf.com/bundle/jamf-protect-documentation/page/Integrating_with_Microsoft_Azure_AD.html

In this post, we will explore how to setup the connection using SAML.

First of all, lets head to Azure AD via portal.azure.com and go to Enterprise Applications and make a new app:

Choose then Create your own application:

Give the app a display name and select Integrate any other application you don't find in the gallery (Ignore the pop-up displaying other similar apps in the Gallery) and then click Create:

Once the app has been created, in the Getting Started section pick 2. Setup single sign on:

Select then SAML:

And then hit the Edit button to configure the app:

The first field to be configured is the Identifier (or EntityID). This will depend based on your tenant.

For example, my tenant is https://matteoistesting.protect.jamfcloud.com/ So the to replace for Entity ID will be: `matteoistesting-protect-jamfcloud-com`

Note the dashes in here, not the dots.

This test tenant I’m using is located in Europe so my Reply URL will be EU—[https://eu-auth.protect.jamfcloud.com/login/callback?connection=matteoistesting-protect-jamfcloud-com](https://eu-auth.protect.jamfcloud.com/login/callback?connection=matteoistesting-protect-jamfcloud-com)

and my Entity ID:

urn:auth0:eu-jamf:matteoistesting-protect-jamfcloud-com

Hit the Save button and that’s it for the SAML configuration.

Scroll then down to the SAML Certificates section and download the:

• Certificate (Base64)

• Federation Metadata XML

We will need to provide those to Jamf to enable the integration.

The last piece of information Jamf will need is the Login URL:

The last step is to assign user and groups to the app. Head to User and Groups, click Add and configure user/groups as needed:

Once we’ve finished, we can reach out to Jamf and provide:

• Certificate and Federation XML we downloaded

• Login URL (as per previous step)

Once Jamf will confirm the SSO has been setup for our tenant, we should see a new Continue with Microsoft** button to show up under the /login URL of our tenant:

And that’s pretty much it. We can click on it and we’ll be redirected to Azure AD tenant for authentication.

Keep in mind, by default Jamf disables IdP initiated logins, for good reasons: https://auth0.com/docs/authenticate/protocols/saml/saml-sso-integrations/identity-provider-initiated-single-sign-on

This means we can’t launch Protect console from our AzureAD profile. If you’re ok with having IdP initiated login enabled, just let Jamf know and they will enable it for you.

I have been playing since then with few other ideas and thought this one was worth to share.

Disclaimer: this is not nearly as close as a production ready workflow, it’s mainly a personal learning project to familiarize with python, webhooks and, in general, automation.

What’s the problem we’re trying to solve?

End users with admin privileges could potentially disable Gatekeeper. There’s enough “junk” forums on the net suggesting to turn off Gatekeeper as a solution for very suspicious apps.

From Apple’s website:

“macOS offers the Gatekeeper technology and runtime protection to help ensure that only trusted software runs on a user’s Mac.” https://support.apple.com/en-gb/guide/security/sec5599b66df/web

We could surely rely on Jamf Pro inventory to track when a user disable Gatekeeper, but that would rely on the device submitting an inventory update, which depending on the configuration chosen by the administrators, sometimes it can take hours/days to have fresh data in.

The idea is to leverage Protect “Add to Smart Group” functionality, Jamf Pro webhooks and MDM framework to make the detection and remediation as fast as possible.

How we can work on this.

Let’s start with some diagram to break this down in smaller components.

Key components:

• Jamf Pro

• Jamf Protect

• AWS: API gateway + Lambda + CloudWatch + Secrets Manager

• Jamf Protect will detect that Gatekeper have been disabled (we’ll see later how to) and use the “Add to Smart Group” built in feature to add the device to a Smart Group in Jamf Pro.

• Jamf Pro will fire off a webhook - SmartGroupComputerMembershipChange - to the API gatway

• API gateway passes the content of the webhook (json formatted file) to Lambda.

• Lambda iterate through the file, determine the event (Gatekeeper disabled) and makes an API call to Jamf Pro.We’ll take advantage of the /api/v1/deploy-package api endpoint in Jamf Pro.

• A pkg containing a postinstall script to re-enable Gatekeeper and notify the user is sent to the device.

What I like about this workflow is that it relies on installing the pkg via MDM, instead of a traditional policy using the jamf binary.

Time to get started then!

Let’s first build a detection for Jamf Protect to be able to pick up when an admin user disables Gatekeeper.

We will use an Analytic to help with the detection.

To disable Gatekeeper, the spctl binary can be used, specifically running

spctl --master-disable

First, the predicate for our Analytic:

$event.type == 1 AND 
$event.process.signingInfo.appid == "com.apple.spctl" AND 
$event.process.commandLine CONTAINS[cd] " --master-disable"

For the Event Type we’ll choose Process Event.

To setup the Smart Group integration in Protect and the equivalent Smart Group in Pro we can just follow the docs: https://learn.jamf.com/en-US/bundle/jamf-protect-documentation/page/Setting_Up_Analytic_Remediation_With_Jamf_Pro.html

Cool, so we now have Protect which is detecting when Gatekeeper is disabled and it’s adding the device to a Smart Group in Pro.

We now need to build out our AWS API gateway and Lambda, you can follow my previous blog post for the details: https://skartek.dev/2022/08/24/a-beginners-approach-to-serverless-and-python-to-solve-real-life-scenarios/

Once setup it should look like:

Remember to choose JSON for the content-type as that would help us easily parse in our Lambda which will be written in python.

Once we have our webhook in place, let’s build the actual package that will be installed on the device via MDM.

For the purpose of this exercise I’m keeping it limited to the very basic: We are going to first check if Gatekeeper have actually been disabled. We’ll then use jamfHelper to notify the user they’re not allowed to disable Gatekeeper. We’ll then remove the “tag” Jamf Protect made for this device, as we’ve now re-enabled gatekeeper by clearing up the /Library/Application\ Support/JamfProtect/groups/Gatekeeper_Disabled_EU Finally, we will submit an inventory update to kick the device out of the Smart Group in Jamf Pro as Gatekeeper has now been safely re-enabled.

gatekeeper_status=`/usr/sbin/spctl --status | grep "assessments" | cut -c13-`
if [ $gatekeeper_status = "disabled" ]; then
	/usr/sbin/spctl --master-enable
else
	echo "False Detection"
fi


"/Library/Application Support/JAMF/bin/jamfHelper.app/Contents/MacOS/jamfHelper" -windowType hud -title "Oh... you naughty!" -heading "An attempt to disable Gatekeeper have been detected" -alignHeading natural -description "Disabling Gatekeeper is not allowed!." -alignDescription natural -icon "/System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/AlertStopIcon.icns" -button1 Ok -alignCountdown center -lockHUD

/bin/rm -rf /Library/Application\ Support/JamfProtect/groups/Gatekeeper_Disabled_EU

/bin/sleep 60

/usr/local/bin/jamf recon

You can use your preferred tool to build the package.

Now, once you’ve built the package, there’s a few things we’ll need.

To start, in order to send an InstallEnterpriseApplication MDM command, the pkg needs to be signed. You can follow the superb article from TTG on how to create a signing certificate and how to sign a package: https://travellingtechguy.blog/signing-packages-and-configuration-profiles-with-the-built-in-jamf-pro-certificate-authority/

Once singed, we need the size in bytes as this will need to be used in the manifest which we’ll use to send the MDM command.

stat -f %z Enable_Gatekeeper.pkg 
11111

Lastly, we need to get the MD5 signature of the pkg.

md5 Enable_Gatekeeper.pkg
MD5 (Enable_Gatekeeper.pkg) =
11111111111111111111111111111111

We now have to choose where to host this package. Any HTTPS file share would do, but you could also opt to use an S3 bucket. Create an S3 bucket, upload the pkg and then we’ll need to think how to secure it. You could either leave the S3 bucket open (won’t recommend) or you could make use of pre-signed URLs (basically URLs with an auth token backed in and you can choose the validity of the token).

For the purpose of this exercise, I’m using a manually generated pre-signed URL, valid for 12 hours.

In AWS, S3 choose Object actions and Share with a presigned URL.

Time to get started writing the code of our Lambda.

First of all, we need to thing that Jamf Pro will fire the webhook twice. The webhook is designed to notify of Smart Group membership changes, so it will be fired when the device is added to the Smart Group and also when the device falls out of the Smart Group.

We can build a simple check in our code to identify if the event is device added (and hence action needed) or if it’s being removed (hence remediation has taken place and nothing should be done more.)

output = json.loads(event["body"])
 device_removed = output['event']['groupRemovedDevicesIds']
 device_removed_check = str(device_removed)[1:-1]

 if device_removed_check != "":
 print(f"This webhook have been generated for a device being removed from the Smart Group, nothing to do here. Device ID {device_removed}")
 
 else:
 device_id = output['event']['groupAddedDevicesIds']

After this, we will call Secrets Manager to retrieve the Jamf Pro API user/password.

response = client.get_secret_value(
 SecretId='SecretManager_name_here')
 
 secretDict = json.loads(response['SecretString'])
 api_user = secretDict['username']
 api_password = secretDict['password']

We can then proceed and get a bearer token from the Jamf Pro API.

token_url = f"{jamf_url}/api/v1/auth/token"
 headers = {"Accept": "application/json"}
 
 resp = requests.post(token_url, auth=(api_user, api_password), headers=headers)
 resp.raise_for_status()
 resp_data = resp.json()
 
 print(f"Access token granted, valid until {resp_data['expires']}.")
 
 data = resp.json()
 token = data["token"]

We now need to build the payload, which is actually the manifest.

payload = {
 "manifest": {
 "url": presigned_url,
 "hash": "11111111111111111111",
 "hashType": "MD5",
 "bundleId": "com.jamf.gatekeeper.enable",
 "bundleVersion": "1.0.0",
 "subtitle": "Subtitle",
 "title": "EnableGatekeeper.pkg",
 "sizeInBytes": 11111
 },
 "installAsManaged": False,
 "devices": device_id,
 }
 
 headers={
 "Authorization": f"Bearer {token}",
 "Accept": "application/json"
 }

The hash will be the value we got from the md5 command previously and the sizeInBytes same for the stat command.

Lastly, the actual API call:

response = requests.post(url, json=payload, headers=headers)
 print(f"Jamf Pro API call HTTP Status: {response.status_code}")

The full script can be found on GitHub:

https://github.com/matteo-bolognini/AWS-Projects/blob/main/Gatekeeper_Disabled_Remediation

That’s pretty much it from the configuration and setup side so, time to test this workflow out and see how it looks like:

https://youtu.be/HD99Y8Q3Mho

Well… that’s a wrap!

See you on the next episode :)

Lets start with why I’m even writing this post.

A few weeks ago I got faced with an interesting dilemma.

Say that you configure Conditional Access for your Jamf Pro instance and enroll via Company Portal your iOS devices. You then have a Conditional Access policy to require your iOS devices to be on the latest version. Example: your CA policy has a pass code policy, or a minimum iOS version.

Scenario: you enroll a device, register via Company Portal and shows the end user get a “Your device is non compliant” message. The user then takes action (in our example say updating the pass-code to be compliant with minimum requirements, or update iOS version). Once the user then browse again to any O365 resource or Conditional Access gated resources, will still get a “you’re not compliant” message.

This is because the device inventory in Jamf Pro haven’t been updated, and as consequence, neither the data forwarded from Jamf Pro to Microsoft Endpoint Manager for compliance.

TL;DR I thought it would be nice to have a way to request an Inventory Update from their iOS devices in a simple and secure way, so enough with the theory, lets move to practice.

From an end user prospective, this will be deployed as a WebClip, via MDM.

Overview of the general setup below:

Lets break it down:

• User launch the WebClip which makes an HTTP call to AWS API Gateway
• API Gateway invoke a Lambda function
• Lambda grabs the API username and password of a Jamf Pro API account from Secret Manager (data is encrypted at rest and in transit using KMS)
• Lambda send an API call to Jamf Pro to request an UpdateInventory command to be issued for the specific device_id which requested it.
• Jamf Pro receives the API request and send the UpdateInventory command to the device.

AWS Console - Lambda - part1** Let’s start creating a Lambda function:

Select “Author from scratch”, give it a friendly name and choose your runtime, in this case I’ll choose python as it’s the language I’ll use to write the API call for Jamf Pro.

For now, we want to leave this Lambda as is, just create it and we’ll come back to it later to configure it.

AWS Console - S3 bucket**

This step is optional but I think it adds more value to the end user experience to return an image/GIF when they hit the WebClip, without this step we would only be able to return raw/html formatted text.

Go to S3 section and hit Create Bucket:

**Give it a friendly name and then for this demo we’re ok keeping the rest of the setup to the default one:

Once the bucket has been created, click on hit and go to Properties and copy the ARN:

AWS Console - Secret Manager**

The Lambda itself will not be directly exposed to the internet but given it will be invoked by a public API, lets avoid storing username/password in clear text in it.**What we can do, is instead to store them in Secret Manager, where they will be encrypted with KMS. On execution, Lambda will decrypt those at code level and keep them safe.

Search for Secret Manager and hit Store a new secret**:

In the secret type choose Other type of secret:

Provide the key/value as:

username

password

and the relatively correspondent values, leave encryption to KMS and hit Next:

Give it a secret name and keep it saved, we will use this later in the Lambda code.Save the secret hitting Store Secret

AWS Console - IAM**We now need to grant a few permissions in here. First, we need to give Lambda permissions to read the username/password from Secret Manager. We also need to allow the Lambda to read the images/gif we’re storing on the S3 bucket. Lastly, we want to make sure our Lambda has permissions to log into CloudWatch. If when you created the Lambda function you didn’t specify an execution role, AWS would have created an IAM role for you and defaulted to grant CloudWatch permissions.

You can check in AWS Console > IAM > Roles you should find an IAM role with a name starting with the name of your Lambda function:

If you expand the generated policy, it should include CloudWatch permissions:

We can now create 2 new policies to grant permission respectively for S3:

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Action": [
 "s3:GetObject"
 ],
 "Resource": "arn:aws:s3_bucket_here"
 }
 ]
}

And for retrieving data from Secret Manager:

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Sid": "AllowLambdafucntionReadSecretManager" 
 "Effect": "Allow",
 "Action": [
 "secretsmanager:GetSecretValue",
 ],
 "Resource": [
 "arn:ARN_of_Secret_Manager_Secret_here"
 ]
 }
 ]
}

In both cases replace Resource with the correct ARN of your bucket and secret.

Next we can either create a new IAM role, assign those permissions and run the Lambda with it, or, for simplicity as this is just a demo, I’ll just edit the execution IAM role that was automatically created. Go to the role, click Add permissions and attach the 2 policies we just created.

AWS Console - API Gateway**

We’ll build a simple HTTP API Gateway:

Click on Add integration:

Select Lambda and pick the Lambda function we’ve created before:

Set the method type to GET:

Given this API Gateway will be called via an iOS WebClip, the only HTTP method we have available is GET.

Click on Next on the next steps and complete the API Gateway setup.

Once its done, you should see an invoke ULR similar to this:

Save the invoke URL as we’ll be using that in the WebClip.

AWS Console - Lambda - part2

It’s time now to finally configure the Lambda function.A side note, we need the requests module which by default is not included in python 3.8 or later shipped with the AWS SKD. I found this blog post helpful to get requests available: https://medium.com/@cziegler_99189/using-the-requests-library-in-aws-lambda-with-screenshots-fa36c4630d82

We can now copy and paste in the python code for our lambda:

import requests
import json
import boto3
import base64
s3 = boto3.client('s3')

def lambda_handler(event, context):

 #Define the Jamf Pro URL
 jamf_url = "https://myinstance.jamfcloud.com"
 
 #Define the S3 bucket name(bucket) and filename(key)
 S3_Bucket = "mybucket"
 S3_Key = "myimage.png"
 SecretManagerId = "mysecret"
 ErrorText = "We hit a snag! Please open a ticket to HelpDesk"
 
 #######################################################################################
 ################################# DO NOT MODIFY BELOW #################################
 #######################################################################################
 
 #Extract the device id from the API call HTTP header
 jss_id = event['queryStringParameters']['device_id']
 
 #Invoke Secrets Manager to obtain Jamf Pro API username and password
 client = boto3.client("secretsmanager")
 response = client.get_secret_value(SecretId = (SecretManagerId))
 secretDict = json.loads(response["SecretString"])
 jamf_api_username = secretDict["username"]
 jamf_api_password = secretDict["password"]
 
 #Invoke Jamf Pro API /token enpoint
 token_url = f"{jamf_url}/api/v1/auth/token"
 headers = {"Accept": "application/json"}
 resp = requests.post(token_url, auth=(jamf_api_username, jamf_api_password), headers=headers)
 resp.raise_for_status()
 resp_data = resp.json()
 print(f"Jamf Pro Access Token granted, valid until {resp_data['expires']}.")
 data = resp.json()
 token = data["token"]
 
 jamf_pro_resp = requests.post(
 f"{jamf_url}/JSSResource/mobiledevicecommands/command/UpdateInventory/id/{jss_id}",
 headers={"Authorization": f"Bearer {token}", "Accept": "application/json"},
 )
 
 if jamf_pro_resp.status_code != 401:
 response = s3.get_object(
 Bucket = (S3_Bucket),
 Key = (S3_Key),
 )
 image = response['Body'].read()
 return {
 'headers': { "Content-Type": "image/png" },
 'statusCode': 200,
 'body': base64.b64encode(image).decode('utf-8'),
 'isBase64Encoded': True
 
 }
 print(f"Inventory Update successfully requested - HTTP response: {jamf_pro_resp.status_code}")
 else:
 return {
 'headers': { "Content-type": "text/html" },
 'statusCode': 200,
 'body': "<h1>(ErrorText)</h1>",
 
 } 
 print(f"Check your credentials <POST failed> Jamf Pro API HTTP response: {jamf_pro_resp.status_code}")

Edit the script line 9 to 17 and provide the details of your environment.

At this point, we’re done with the AWS config, all what’s left is to create and deploy the WebClip via Jamf Pro.

Create a Configuration Profile for Mobile Devices.

Within the URL field we will provide the API Gateway URL constructed this way:

https://your_unique_identifier.execute-api.eu-central-1.amazonaws.com/yourAPIGatewayName?device_id=$JSSID

We are adding the

?device_id=$JSSID

so that when the Configuration Profile is deployed, Jamf Pro will insert each device_id into the URL. The device_id is then fetch in Lambda.

The Config Profile should then look like this:

Scope as needed and Save.

Now let’s wrap it up and see if it works:

https://youtu.be/l_By0cFaMrI

Not the most elegant notification in the WebClip but for this demo would suffice. We can see the Update Inventory command being issued successfully.

Well, that’s a wrap!

First, let’s login to https://admin.google.com and expand the Apps section and locate and open Web and mobile apps:

Next we want to select Add app and then Add a custom SAML app:

**We can now start configuring our SAML app. Lets give it an App name, that would be the display name of the app, eventually a description to help keep track of what this SAML app is linked to, and an icon (optional):

We can then hit Continue and move to the next page.

In here, we will download the metadata file. This is a unique per SAML app file, which contains the information of this app. You want to save this file somewhere safe as it is the one you will need to send Jamf to enable SSO for the Protect tenant:

The next step after we move on clicking Continue, is to configure the ACS URL and the Entity ID.

For those, we can refer Jamf’s documentation:

https://docs.jamf.com/jamf-protect/documentation/Integrating_with_Google_Cloud.html

For example, my tenant is https://matteoistesting.protect.jamfcloud.com/ So the to replace for both ACS URL and Entity ID will be:

matteoistesting-protect-jamfcloud-com

Note the dashes in here, not the dots.

This test tenant I’m using is located in Europe so my ACS URL will be EU—https://eu-auth.protect.jamfcloud.com/login/callback?connection=matteoistesting-protect-jamfcloud-com

and my Entity ID:

urn:auth0:eu-jamf:matteoistesting-protect-jamfcloud-com

Once we’ve configured ACS URL and Entity ID accordingly to our tenant, we want to setup the Name ID format** and set that to EMAIL:

Lets hit continue and move to the last step of configuring the SAML app. We will leave the default configuration here so we can click on Finish to have Google Workspace build the SAML app:

Once the SAML app have been successfully crated, note that by default, it will not be enabled, see the OFF for everyone:

Lets click on it and enable it by setting it to ON for everyone:

The very last step now is to assign user groups to our SAML app:

**This is a very important step as, assigning those groups, will translate in granting access to Jamf Protect only to Google Workspace users that are member of such groups.

Once we’ve finished, we can reach out to Jamf and provide:

• Google Workspace domain
• IdP metadata file

Once Jamf will confirm the SSO has been setup for our tenant, we should see a new Continue with Google** button to show up under the /login URL of our tenant:

And that’s pretty much it. We can click on it and we’ll be redirected to Google Workspace for authentication.

Keep in mind, by default Jamf disables IdP initiated logins, for good reasons: https://auth0.com/docs/authenticate/protocols/saml/saml-sso-integrations/identity-provider-initiated-single-sign-on

This means we can’t launch Protect console from our Google Workspace profile. If you’re ok with having IdP initiated login enabled, just let Jamf know and they will enable it for you.

I couldn’t think of any different introduction to approach Unified Logging rather than this statement that is my personal mantra of troubleshooting/looking into any issue when it comes to end user devices. Logging is the unique base for any device related issue for sure. But it can be much more, offering an insight and overview of apps, technologies and products running on our devices.

Where to start?

Traditionally, macOS and any 3rd party have logged into the “standard” location of /var/log , de facto writing out logs into files on disk.

Apple introduced radical changes in with macOS 10.12.x where Apple moved the system and process logs to a unified database on the Mac.

Let’s start with some references:

• Apple Unified Logging Documentation - https://developer.apple.com/documentation/os/logging
• Apple WWDC 2016 Into to Unified Logging - https://developer.apple.com/videos/play/wwdc2016/721/
• “Unified Logging and Activity Tracing” - WWDC 2016, Session 721 - https://devstreaming-cdn.apple.com/videos/wwdc/2016/721wh2etddp4ghxhpcg/721/721_unified_logging_and_activity_tracing.pdf

The last one is a very comprehensive session, lets try to over-simplify the content and try to describe what Unified Logging is, in a nutshell:

• Single efficient logging mechanism, offering a comprehensive and performant API
• Maximize information collection with minimum observer effect
• Compression of log data
• Managed log message lifecycle more than just time stamps
• a common system across macOS, iOS, watchOS, tvOS
• Designed with Privacy in mind and a Privacy first mindset

Now that we have a bit of background of what Unified Logging is (UL for brevity in this post), let’s dig a bit more into.

Logs are stored in the tracev3 formatted files in /var/db/diagnostics, which is a compressed binary format. As with all binary files, you’ll need new tools to read the files. The Console.app is a great UI to explore the logging, but it can be quite overwhelming.

To get our hands on logs, we can use the log command, on macOS - /usr/bin/log

To get more information, simply open the Terminal.app and run: man log

The log command can be used to Collect and View Unified Logging data and. There are 3 main verbs for the log command that is particularly interesting to look at:

• log collect --output path this allow us to generate a .logarchive file
• log show this allow us to have macOS produce a log file of everything we’ve specified in our filter search, limited by time using the --last flag, for example if we’re interested only on the last 60 minutes of logging we will set --last 1h
• log stream this is a live streaming of everything we’ve specified in our filter search, it will not show any historical data, only starting from when the command is executed.

Ok, so that’s it? Simple, we can now just go in Terminal.app and run log show! Yes, but no. If you try that, you’ll see how comprehensive and extensive UL is, you will basically be flooded by information. We’ve seen above we can use the --last flag to time-restrict the search and limit the logging to a specific period of time (we can go as low as 1 minute). But that is not sufficient, given the verbosity of the output.

Here in rescue comes Predicates**! As usual, lets first start with the docs: https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/Predicates/Articles/pSyntax.html Predicates are an option that provide granular control over filtering and provide the logic to confine a search to specific values. Predicates gets hooked up in the log command query filter:

log steam --predicate '(predicate_here)'

For example, we can filter looking at data from Safari:

log stream --predicate '(process=="Safari")'

Predicates available:

 eventType The type of event: activityCreateEvent, activityTransitionEvent, logEvent, signpostEvent, stateEvent, timesyncEvent, traceEvent and
 userActionEvent.

 eventMessage The pattern within the message text, or activity name of a log/trace entry.

 messageType For logEvent and traceEvent, the type of the message itself: default, info, debug, error or fault.

 process The name of the process the originated the event.

 processImagePath The full path of the process that originated the event.

 sender The name of the library, framework, kernel extension, or mach-o image, that originated the event.

 senderImagePath The full path of the library, framework, kernel extension, or mach-o image, that originated the event.

 subsystem The subsystem used to log an event. Only works with log messages generated with os_log(3) APIs.

 category The category used to log an event. Only works with log messages generated with os_log(3) APIs. When category is used, the subsystem
 filter should also be provided.

Now the last one in the list, subsystem, is a very interesting one as it becomes very helpful to narrow down the search filter. Charles Edge krypted did a great job providing a list of Apple’s subsystems: https://gist.github.com/krypted/495e48a995b2c08d25dc4f67358d1983

For any other .app on a device, we can pull its subsystem from the Info.plist using a command like the below:

defaults read /Applications/APP_NAME.app/Contents/Info.plist CFBundleIdentifier

Example with Jamf Protect:

$ defaults read /Applications/JamfProtect.app/Contents/Info.plist CFBundleIdentifier com.jamf.protect.daemon

In this example, if we would like to stream Jamf Protect data logged, a very simple UL search could be like:

log stream –predicate “subsystem == ‘com.jamf.protect.daemon’

Some examples from Apple’s man page:

Filter for specific subsystem:
log show --predicate 'subsystem == "com.example.my_subsystem"' 


Filter for specific subsystem and category:
 log show --predicate '(subsystem == "com.example.my_subsystem") && (category == "desired_category")'


 Filter for specific subsystem and categories:
 log show --predicate '(subsystem == "com.example.my_subsystem") && (category IN { "category1", "category2" })'


 Filter for a specific subsystem and sender(s):
 log show --predicate '(subsystem == "com.example.my_subsystem") && ((senderImagePath ENDSWITH "mybinary") || (senderImagePath ENDSWITH "myframework"))'

Log verbosity. There are different level of logging verbosity available:

• Default
• Info
• Debug
• Error
• Fault

Unless specified, the Default logging level is always the default (who would have guessed) level. This can be configured in the UL filter:

log (stream/show) --predicate (--debug/ --info)

In some specific scenarios, it is useful to enforce the default logging of a binary (or an app) to debug for troubleshooting purposes. To ensure debug level logging is saved for a given subsystem you can run one of these commands:

log config --subsystem "com.jamf.management.daemon"--mode "level:debug,persist:debug"

log config --subsystem "com.jamf.management.binary"--mode "level:debug,persist:debug"

Make sure to reset to default settings once done:

log config --subsystem "com.jamf.management.daemon" --reset

log config --subsystem "com.jamf.management.binary" --reset"

Logging levels can also be deployed via MDM: https://developer.apple.com/documentation/devicemanagement/systemlogging

<plist version=”1.0”>
<dict>
 <key>PayloadContent</key>
 <array>
 <dict>
 <key>Processes</key>
 <dict/>
 <key>Subsystems</key>
 <dict>
 <key>com.example.app</key>
 <dict>
 <key>DEFAULT-OPTIONS</key>
 <dict>
 <key>Level</key>
 <dict>
 <key>Enable</key>
 <string>Info</string>
 </dict>

Now that we have explored a bit how Unified Logging is built, what’s the data structure and interactions, let’s see some Jamf related examples of UL filters:

We can start with a very basic streaming for the management framework using either the info or debug log verbosity level:

/usr/bin/log stream --predicate 'subsystem BEGINSWITH "com.jamf.management"' --level info

/usr/bin/log stream --predicate 'subsystem BEGINSWITH "com.jamf.management"' --level debug

Or, for example, we can look at specific days only and restrict our search to those only - for example last month of logs - date format YYYY-MM-DD:

/usr/bin/log show --predicate 'subsystem BEGINSWITH "com.jamf"' --style compact --debug --start '2022-04-01' --end '2022-05-01'

Or we can also format for a specific time range: YYYY-MM-DD HH:MM:SS:

/usr/bin/log show --predicate 'subsystem BEGINSWITH "com.jamf"'--style compact --debug --start '2022-05-02 10:00:00'--end '2022-05-02 11:00:00'

Last mention on privacy. As we saw, Unified Logging is designed to not log any kind of private information. For investigation purposes, this might be disabled. Within the SystemLogging documentation, there is mention of a specific key that can enable the logging of Private Data:

 <key>Enable-Private-Data</key>
 <true/>

As an example, we can look at some Safari UL logging obtained with a filter like the below:

log stream --predicate '(process == "Safari" and message contains "Look up" || message contains "databases")' --debug

Without Enable-Private-Data set to true (or with the key pair set to false), when browsing to a website URL within Safari, the actual URL is masked behind a <private>

` Debug 0x0 592 0 Safari: (SafariSafeBrowsing) [com.apple.Safari.SafeBrowsing:Lookup] Look up a ur`l

When Enable-Private-Data is enabled, with the same UL filter we can actually see the ULR that has been browsed:

` Debug 0x0 592 0 Safari: (SafariSafeBrowsing) [com.apple.Safari.SafeBrowsing:Lookup] Look up a url https://www.google.com/`

Keep in mind that Private-Data is completely transparent to the end-user if it’s enabled. If should only be enabled for specific troubleshooting purposes and disabled immediately after testing is completed.

As we’ve seen, Unified Logging is extremely powerful and can be very very flexible. If offers virtually unlimited customization.

A very good example of usage can be found here https://www.modtitan.com/2022/03/in-weeds-with-app-installers-preview.html where Dr. K brilliantly debugged Jamf’s App Installers using Unified Logging filters.

What usage can be made of UL then?

For instance, an example is provided by Jamf Protect, which can pull specific UL filtered logs and ship them onto a SIEM of your choice. There’s quite a few UL filters example on the Protect GitHub repository: https://github.com/jamf/jamfprotect/tree/main/unified_log_filters

First of all, where do we start from? Of course the documentation!**https://docs.jamf.com/jamf-now/documentation/Jamf_Connect_Deployment.html

Before we dig into, I’d like to stress this feature is currently on Preview and as per the documentation it states: “Previews give you a first look at upcoming features and functionality, and allow you to provide feedback and submit defects to our software developers. Preview features and documentation are provided for testing purposes and should not be considered final.”

This feature is currently supported for Okta and AzureAD. Similar to the “complete suite” that is Jamf Connect, this new iteration on Jamf Now allows to synchronize the local account password on a Mac with the Okta/AzureAD password so both of them are in sync and, most importantly, if there is a mismatch of the local account password, prompt the user to change the local password so it matches the IdP password and get FileVault password updates as well.

Ok time to start with the setup. In this example I will use Okta but pretty much the same steps applies for AzureAD ref: https://docs.jamf.com/jamf-connect/2.7.0/documentation/Integrating_with_Microsoft_Azure_AD.html#ID-00001cea).

First of all, again documentation on how to create the Okta app: https://docs.jamf.com/jamf-connect/2.7.0/documentation/Integrating_with_Okta.html

Once logged in the Admin console, we’ll head over to

• Applications** > Create App Integration

In the next screen we’re gonna select:

1. OIDC - OpenID Connect as the sign-in method.3.Native Application as the application type.

1. Give the app a name in the Application name field.

2. Set Authorization Code to Implicit (hybrid) in the Grant type section

1. For this example, we will assing this app to ALL users within the org

1. Most important step of all, click Save.

We now have configured our Okta app, so it’s time to head over to Jamf Now.

Within our Jamf Now Blueprint lets head to the Security section and enable the Enable Jamf Connect checkbox.

This will bring up the configuration menu. Lets switch to Okta in the Identity Provider field and provide our Okta tenant (domain)

There is a built in webui to test the configuration. Most likely you will get an error like

This is just expected as, by default, Okta is not allowed to be embedded in an iFrame.I don’t recommend this but you can change this setting by logging as admin and going to Settings -> Customization -> IFrame Embedding and checking “Allow IFrame embedding”

Once this is done, if you revisit the Blueprint and click again on Test, you’ll notice the Okta UI login should now be displayed.

Once we’re at this point, the configuration is pretty much completed we can save and wait for the Blueprint to sync on the device.

Digging into a bit we’ll find 2 components will be installed on the device:

1. A Configuration Profile, containing the Okta setup and config

2. An application in /Applications. This is the actual app used to keep password in sync. On this first iteration of the Preview, the app won’t auto-launch and needs to by launched manually by the user

Finally, lets have a look at how it all works. In this short video we’ll see

• a user opening the Jamf Connect application
• getting a prompt to provide the Okta password
• a second prompt to provide the local account password This is the point where Connects kicks in, identify the user’s Okta password is not matching the local account password and proceed to change the local account password to match the Okta one and update the FileVault password as well.

https://youtu.be/sgZ4pApj3dw

The Connect app also gives the user ability to change/reset their Okta password via the menu bar app. This ensures that when changing the Okta password, the local account and FV passwords are all kept in sync as well.

Hope it helps :)

Protect offers a seamless integration with Jamf Pro (ref: https://docs.jamf.com/jamf-protect/documentation/Jamf_Protect_Deployment.html) but can also be extremely easily deployed via Jamf Now in few simple steps.

To deploy Jamf Protect we need 2 basic items:

• a Configuration Profile that contains anything that the agent needs (certificates, keychain items etc)
• and a pkg that is the actual application installer

Let’s get into!

First we’re going to login to our Protect tenant. We will then go to Plans and either select an existing Plan or make a new one. If you’re making a new Plan, please refer to https://docs.jamf.com/jamf-protect/documentation/Plans.html

Within our Plan, we want to make sure the Auto-Update feature is turned on:

This will ensure that every time a new version of Protect is released, we do not have to worry about re-packaging or mananing the updated, but the agent itself will auto-update without intervention.

Next we’re gonna download a Configuration Profile for our Plan by clicking the “Download” button into the “Custom Profile” section.

Lastly, we want to hop into Protect > Administrative > Downloads and download the installer:”

Now that we have both a pkg and the Configuration Profile downloaded from the Protect tenant, we can hop into Jamf Now console.

First we will go into Apps > Add an App

If this is the first time you add a custom app, you’ll see a screen like the above, otherwise it you’ll see a list of your current apps and the “Add an App” button would be in the top right of the screen.

The process is very simple, simply drag and drop in the app we downloaded from Protect:

https://youtu.be/1lietbkPa6M

Now that we have our pkg uploaded, we can add it to a Blueprint for deployment. Let’s go in our Blueprint > Apps > Custom App > Add App

and add the Jamf Protect pkg making sure “Install Automatically” gets enabled

Lastly, we can go to Custom Profiles and click on “Add a Custom Profile” to upload:

The process should look like this:

https://youtu.be/f4-CCWcVpVQ

Let’s bring it all together now and do a test. I’m going to enroll a test device via Open Enrollment and then check for the Configuration Profile and pkg auto deployment:

https://youtu.be/2iPqxi0qx0s

What this means is that you can have an S3 bucket to ingest data that the macOS clients send over to Jamf Protect cloud tennant.

As per Jamf’s documentation; only data that is sent to the Jamf Protect Cloud via an action configuration (alerts, logs, and unified logs) can be forwarded to Amazon S3:**https://docs.jamf.com/jamf-protect/administrator-guide/Release_History.html

What we will need to setup the integration:

• an existing S3 bucket
• an IAM role that Jamf Protect will assume when forwarding data over to S3

Jamf also provide a nice CloudFormation template that can configure everything we need (S3 bucket and IAM role) for us.

Download CloudFormation template**

Let’s first download the CloudFormation template from the Jamf Protect tennantOnce logged in, we can get the template from the Administrative > Data section

Once we have our template, we can head over to ASW and create the IAM role that will be used to run the CloudFormation stack.** Setup IAM role 1.** Login to the AWS console2. Once at the Dashboard search for IAM

3. Select Roles from the side menu bar

1. Click Create role

1. When prompted to Choose a use case, select CloudFormation and click Next:Permissions

1. Click Create policy**This will open a new tab in the browser

1. In the next Policy editor builder click JSON**

8. **Before proceeding with this, I need to specify something.What we’re doing now is to give permission to this IAM user to run the CloudFormation template. This won’t be the IAM user that Jamf Protect will assume when forwarding the logs, such user will be created by the CloudFormation template. The IAM user we’re about to create will need to exist only for the time needed to CloudFormation to run our stack.

To be specific, this IAM role will neeed to be able to perform 3 actions  - create an S3 bucket

• modify it’s policy
• and create an IAM role (the one Jamf Protect will assume)

That said the below is the permissions set I’ve found “safe enough” for my test env. In any production env please do NOT use this snippet and consult with your AWS IAM admin on the needed permissions to bee granted. I’ll grant those permissions to my IAM role and then delete the role as soon as the CloudFormation stack will be completed

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Action": [
 "s3:CreateBucket",
 "s3:DeleteBucket",
 "s3:DeleteBucketOwnershipControls",
 "s3:DeleteBucketPolicy",
 "s3:DeleteBucketWebsite",
 "s3:DeleteObject",
 "s3:DeleteObjectTagging",
 "s3:DeleteObjectVersion",
 "s3:DeleteObjectVersionTagging",
 "s3:GetBucketAcl",
 "s3:GetBucketCORS",
 "s3:GetBucketLocation",
 "s3:GetBucketLogging",
 "s3:GetBucketNotification",
 "s3:GetBucketObjectLockConfiguration",
 "s3:GetBucketOwnershipControls",
 "s3:GetBucketPolicy",
 "s3:GetBucketPolicyStatus",
 "s3:GetBucketPublicAccessBlock",
 "s3:GetBucketRequestPayment",
 "s3:GetBucketTagging",
 "s3:GetBucketVersioning",
 "s3:GetBucketWebsite",
 "s3:GetEncryptionConfiguration",
 "s3:ListAllMyBuckets",
 "s3:ListBucket",
 "s3:ListBucketVersions",
 "s3:PutBucketAcl",
 "s3:PutBucketCORS",
 "s3:PutBucketLogging",
 "s3:PutBucketNotification",
 "s3:PutBucketObjectLockConfiguration",
 "s3:PutBucketOwnershipControls",
 "s3:PutBucketPolicy",
 "s3:PutBucketPublicAccessBlock",
 "s3:PutBucketRequestPayment",
 "s3:PutBucketTagging",
 "s3:PutBucketVersioning",
 "s3:PutBucketWebsite",
 "s3:PutEncryptionConfiguration"
 ],
 "Effect": "Allow",
 "Resource": "*"
 },
 {
 "Action": [
 "iam:AttachRolePolicy",
 "iam:CreateRole",
 "iam:DeleteRole",
 "iam:GetAccountPasswordPolicy",
 "iam:GetGroup",
 "iam:GetGroupPolicy",
 "iam:GetPolicy",
 "iam:GetPolicyVersion",
 "iam:GetRole",
 "iam:GetRolePolicy",
 "iam:GetUser",
 "iam:GetUserPolicy",
 "iam:ListPolicies",
 "iam:ListRolePolicies",
 "iam:ListRoleTags",
 "iam:ListRoles",
 "iam:ListUserTags",
 "iam:ListUsers",
 "iam:PutRolePolicy",
 "iam:PutUserPolicy",
 "iam:TagRole",
 "iam:TagUser",
 "iam:UntagRole",
 "iam:UntagUser",
 "iam:UpdateRole",
 "iam:UpdateRoleDescription"
 ],
 "Effect": "Allow",
 "Resource": "*"
 }
 ]
}

9.** Paste in your policy and click Review policy

10. **Review your policy and give it a friendly **Name and if you want, add a Description Once you’re set, hit Create policy

**11. **Go back to the IAM role creation page and search for the newly created policy

12. **Select the policy by ticking the box and click **Next:Tags

13. (Optional) add in any key pair tags and then click Next:Review

14. **Choose a name for the IAM role and then click **Create Role

CloudFormation stack

1. Now that we have our “build” IAM role with its own permissions granted with the Policy let’s go to CloudFormation and build our stack in AWS console click Services and type in CloudFormation

2. **In the CloudFormation dashboard click **Create stack

3. Leave Prepare template set to the default and switch Specify Template to Upload a template file and use the Choose file button to upload the template we downloaded from Jamf Protect.Once the template is uploaded click Next

4.Choose a Stack name**This is mostly an identifier to check your stack building later

5.** Choose a name for the S3 bucketThe JamfProtectBucketName is the variable in the stack template, in this field we’re giving the stack which value should be used to create the S3 bucket, that will be named based on what is provided in this field

6. Click Next

7. In the Configure stack options section scroll down to Permissions and select the IAM user we created before

8. Scroll to the bottom of the page and click Next

9. **Review your stack build and give consent to CloudFormation to use the IAM role permissions and then click **Save stack

CloudFormation will now process the Stack we configured and will display us the status

The page sometimes it’s a little bit slow in the background auto-refresh, if needed use the refresh button

Let’s break down what the stack did**First it created a Policy for the S3 bucket

Then it creates an IAM role. This is the role that Jamf Protect will assume when sending data over to the S3 bucket

Lastly it creates the S3 bucket

If we go back to IAM** > Roles we can now see the role the Stack created in a format with the name we choose for the stack with -JamfProtectWriterRole-UNIQUEID appended to.

If we go to S3 we can also see the newly created bucket with the name we choose

One last thing, just to keep things clean, now that the CloudFormation stack has successfully completed, we can go back in IAM > Roles > select our “build” IAM role that was created with the sole purpose of being used by this stack and delete it

Configure Jamf Protect to forward data to S3

**Now that we have an S3 bucket and an IAM role enable to POST data we just need to configure Jamf Protect to forward data.

1. Once logged in, we can get the template from the **Administrative > Data section and on the Amazon S3 Bucket Name simply provide the name of the S3 bucket the stack created for us

2. Provide a Prefix

**3. **Now go back to AWS > IAM > Roles > select the role the stack created for us and copy the ARN name

**4. **Paste the IAM Role ARN into Jamf Protect

5. Click Save

6. Go to the Actions > choose your deployed Action > Edit and enable the data forwarding option

How to verify the integration is completed? Head back to S3 and we should now have a directory on our S3 bucket

Inspecting the content of the few directories there and we should fine a file posted as a test by Jamf Protect to check all is good, should be something like

And that’s pretty much it. From now on, alerts, logs, and unified logs that will be sent over to the Jamf Protect cloud instance will also be forwarded to our AWS S3 bucket and be stored there.