As part of a project I’m working on, I need to run several policies from a Jamf Pro server using a script which is using the Jamf Pro agent to run policies. However, I also want to maintain maximum flexibility and retain the ability to add, remove or change policies as required without needing to change the script.

My colleague Marc provided a solution for this by letting me know that it was possible to use the Jamf Pro API to pull down a list of policies associated with a specific category and then running those policies in the order provided by the API. For more details, see below the jump.

I was able to use Marc’s technique in the following way:

1. Run the following command to get the policy IDs:

2. Add all policy IDs into a bash array.

3. Run each policy in the order they were added to the bash array, which will be the same order provided by the API.

To set the order for the policies, I need to use numbering as part of the policy name. So when naming the policies. the first policy name starts with 010, the second policy’s name begins with 020 and so on.

Once the policies are in place, a script like the one shown below can be used to access the list of policy IDs via the API and run the policies in their specified order.

The script is also available on Github at the following address:

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/Casper_Scripts/run_all_jamf_pro_policies_in_specified_category

If you want to run this script from your Jamf Pro server, it should be set up as follows.

To use this capability, you will need to set up a category if needed and assign your policies to it. For this example, I’ve created a category named InitialSetup.

Once created, assign your policies to this category. If needed, rename the policies to include numerical values. The number values will designate the order for the policies to run.

Once the category and policies have been set up as desired, you can have a separate policy or other means run the script. The script will need to have the following information specified:

• API username
• API password
• Category name

One notable thing about running policies using this technique is the affected policies do not need to be associated with any of the usual triggers.

Instead, the policy is being called directly by its ID number, which in this case will act as a trigger to run the policy:

jamf policy -id policy_id_number_goes_here

As a follow-up to my previous post about running multiple Jamf Pro policies via the API, my colleague John Kitzmiller pointed out that it was possible to achieve similar functionality by using a custom trigger. For more details, see below the jump.

A Jamf Pro policy can be called using a keyword by setting a custom trigger.

This keyword can then be run using the following command:

jamf policy -event trigger_keyword_goes_here

You can also use the custom trigger synonym of trigger instead of event in the command.

jamf policy -trigger trigger_keyword_goes_here

To set the order for the policies called by the custom trigger, I need to use numbering as part of the policy name. The first policy name starts with 010, the second policy with 020 and so on.

Once the policies are in place, a script like the one shown below can be used to run the policies in their specified order by calling the custom trigger’s keyword.

The script is also available on Github at the following address:

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/Casper_Scripts/manual_trigger

If you want to run this script from your Jamf Pro server, it should be set up as follows.

To use this capability, you will need to set the custom trigger with each of the policies you want to run and then set the script to use that custom trigger. The script will send the custom trigger to the Jamf Pro server, which will then run all policies associated with the custom trigger keyword in the specified order.

As part of working on a project recently, I ran into an unexpected problem with ESXi-hosted Mac VMs. For these VMs, I was creating VMDK files from AutoDMG-generated disk images, using vfuse to convert the disk image into a VM with ESXi-compatible VMDK disk image files.

My workflow looked like this:

1. Create disk image using AutoDMG.
2. Use vfuse to create VMDK files using a command similar to the one shown below:

sudo vfuse -i /path/to/autodmg_created_disk_image_here --esx

3. Upload the VMDK files to a convenient location on my ESXi server
4. Set up a new VM, using copies of uploaded VMDK files for the VM boot disk.
5. Resize the new VM to the desired size using VMware’s vmkfstools utility.
6. Start up the VM.

After logging in, I ran the following command to enable macOS to recognize and use the unallocated space from the VM resizing:

diskutil resizeVolume / R

Normally, this command is able to do a live re-sizing of the boot partition to use all available unallocated space. However, this time the re-sizing process failed and the following error was displayed:

How to fix this? For more details, see below the jump.

My research on this problem turned up the following links:

• Unable to extend a partition using the guest Disk Utility after extending disk of a virtual machine running Mac OS X (2069255)
• Expand OS X virtual disk in esxi

Both posts confirmed that this was a known issue, but neither offered viable fixes for the problem I was seeing. After some discussion with Nick Cobb in the MacAdmins Slack, I noticed this section of the error message I had received:

Your partition map does not use the entire space of your whole-disk. You should use "diskutil repairDisk" and then repeat this command.

After some testing, the following command resolved the problem I was seeing:

diskutil repairDisk /dev/disk0

Once the diskutil repairDisk command had been run to fix the partition map, I verified that the following command could now resize the partition without problems:

diskutil resizeVolume / R

To automate the process, I wrote a script to run the repairDisk command. However, repairDisk asks for a Yes/No confirmation before running.

The answer in this specific situation is always going to be “yes”, so the yes command is piped into the command to automatically provide a “yes” answer to the confirmation dialog.

As part of my testing workflow, I’ve been using VMs running on a ESXi server running ESXi 6.5. To help me quickly build those VMs, I have been using a script named esxi_macos_vm_creation.sh for building VMs. This script is forked from Tamas Piros’s auto-create script for standing up Linux VMs on free ESXi:

https://github.com/tpiros/auto-create

My fork of the auto-create script is designed to create and configure virtual machines with Apple operating systems as the guest OS, hosted on a VMware ESXi server running on Apple hardware. The script assumes that the virtual machines are built using copied VMDK disk files, where the VMDK files are generated by AutoDMG and vfuse. For more details, see below the jump.

Building VMDK files

In the process I’m following, the workflow to generate the VMDK files works like this:

1. Create disk image using AutoDMG. The disk image includes a firstboot package, which includes tools to configure the VM on its first startup.

2. Once the disk image is generated, use vfuse to create VMDK files using a command similar to the one shown below:

3. vfuse will create a VM for VMware Fusion. To access the VMDK files, right-click on the VM and select Show Package Contents.

4. The VMDK files will be inside. The conversion process will create two files:

• filename.vmdk
• filename-flat.vmdk

This is expected behavior and both of these files will be needed.

Uploading VMDK files

Once the VMDK files are created and available, they need to be uploaded to a convenient location on an ESXi datastore. For information on how to upload these files, see the link below from the VMware documentation for vSphere:

Upload Files to Datastores:
https://pubs.vmware.com/vsphere-65/index.jsp?topic=%2Fcom.vmware.vsphere.storage.doc%2FGUID-58D77EA5-50D9-4A8E-A15A-D7B3ABA11B87.html

The esxi_macos_vm_creation script will need to be stored on the ESXi server, so also upload it to a convenient location on an ESXi datastore.

Running the script

This script is designed to create and configure virtual machines running Apple operating systems, hosted on a VMware ESXi server running on Apple hardware. The script assumes that the virtual machines are built using copied VMDK disk files. In this case, the VMDK files will be the disk images created by AutoDMG and converted to VMDK files using vfuse.

Note: When creating the VM, you will need to provide the location of the filename.vmdk file . As long as filename.vmdk and filename-flat.vmdk are both available in the same directory on the datastore, ESXi will automatically also reference and include filename-flat.vmdk when creating the VM.

The script is designed to be stored on an ESXi datastore and run from the ESXi server’s command line interface, which is why it needed to be uploaded to an ESXi datastore in the previous step.

Usage:

/path/to/esxi_macos_vm_creation.sh -n -d -c -h -i -o -r -s -v -p

Options:

• -n: Name of VM (required)
• -d: Location of a VMDK disk file (required). Location must be in this format – /vmfs/volumes/datastore_number_here/path/to/filename_here.vmdk
• -c: Number of virtual CPUs
• -h: VMware Hardware Version
• -i: Location of an ISO image. Location must be in this format – /vmfs/volumes/datastore_number_here/path/to/iso_file.iso
• -o: Apple OS version
• -r: RAM size in MB
• -s: Disk size in GB
• -v: VNC port between 5900 and 5909
• -p: VNC password. Maximum password length is eight characters.

The script has several default variables set up:

ESXi datastore location for new VMs: /vmfs/volumes/datastore1
Number of processors for new VMs: 2
Amount of RAM for new VMs: 4096 MBs
Hard drive size for new VMs: 40 GB
Guest OS: darwin14-64 (this is the OS setting for OS X Yosemite.)
Hardware Version: 11 (this is the maximum Hardware Version available for ESXi 6.0.x)

The ESXi datastore value can be changed by editing the DATASTORE variable in the script. The other default values are overridden if alternate values are enabled by the script’s available options.

Examples

To set up a VM specifying only the VM name and VMDK location:

/path/to/esxi_macos_vm_creation.sh -n VM_Name_Goes_Here -d /vmfs/volumes/datastore_number_here/path/to/filename_here.vmdk

The output should appear similar to that shown below:

computername:~ username$ ssh root@esxi.demo.com
Password:
The time and date of this login have been sent to the system logs.

VMware offers supported, powerful system administration tools.  Please
see www.vmware.com/go/sysadmintools for details.

The ESXi Shell can be disabled by an administrative user. See the
vSphere Security documentation for more information.
[root@esxi:~] /path/to/esxi_macos_vm_creation.sh -n macOSVM -d /vmfs/volumes/datastore1/template/filename.vmdk
Destination disk format: VMFS thin-provisioned
Cloning disk '/vmfs/volumes/datastore1/template/filename.vmdk'...
Clone: 100% done.
Powering on VM:
The Virtual Machine is now configured and the VM has been started up. The VM is set to use the following configuration:
Name: macOSVM
CPU: 2
RAM: 4096
Guest OS: darwin14-64
Hardware Version: 11
Hard drive size: 40
No ISO added.
VNC not enabled.
[root@esxi:~]

To set up a VM using a name with spaces and/or special characters, add quotation marks to the VM name:

/path/to/esxi_macos_vm_creation.sh -n "VM's Name Goes Here!" -d /vmfs/volumes/datastore_number_here/path/to/filename_here.vmdk

Other flags can be added as needed:

To set up a VM and add more CPUs:

/path/to/esxi_macos_vm_creation.sh -n VM_Name_Goes_Here -c 4 -d /vmfs/volumes/datastore_number_here/path/to/filename_here.vmdk

To set up a VM and enable VNC on port 5901 with the password set to the word password:

/path/to/esxi_macos_vm_creation.sh -n VM_Name_Goes_Here -d /vmfs/volumes/datastore_number_here/path/to/filename_here.vmdk -v 5901 -p password

To set up a VM named MacOS VM 10.12 using a VDMK stored on /vmfs/volumes/datastore1/template and named macos-vm.vmdk with 4 CPUs, 8 GBs of RAM, a 52 GB hard drive, set to HW Version 13, guest OS set to macOS Sierra and VNC enabled on port 5902 with the VNC password set to the word password:

/path/to/esxi_macos_vm_creation.sh -n "MacOS VM 10.12" -d /vmfs/volumes/datastore1/template/macos-vm.vmdk -c 4 -r 8192 -s 52 -h 13 -o darwin16-64 -v 5902 -p password

The output should appear similar to what’s shown below:

computername:~ username$ ssh root@esxi.demo.com
Password:
The time and date of this login have been sent to the system logs.

VMware offers supported, powerful system administration tools.  Please
see www.vmware.com/go/sysadmintools for details.

The ESXi Shell can be disabled by an administrative user. See the
vSphere Security documentation for more information.
[root@esxi:~] /path/to/esxi_macos_vm_creation.sh -n "MacOS VM 10.12" -d /vmfs/volumes/datastore1/template/macos-vm.vmdk -c 4 -r 8192 -s 52 -h 13 -o darwin16-64 -v 5902 -p password
Destination disk format: VMFS thin-provisioned
Cloning disk '/vmfs/volumes/datastore1/template/macos-vm.vmdk'...
Clone: 100% done.
Grow: 100% done.
Powering on VM:
The Virtual Machine is now configured and the VM has been started up. The VM is set to use the following configuration:
Name: MacOS VM 10.12
CPU: 4
RAM: 8192
Guest OS: darwin16-64
Hardware Version: 13
Hard drive size: 52
No ISO added.
VNC Port: 5902
VNC Password: password
[root@esxi:~]

The script is available below. It is also available from GitHub at the following address:

https://github.com/rtrouton/esxi_macos_vm_creation

As more Mac environments move away from binding Macs to Active Directory and using AD mobile accounts, and towards using local accounts in combination of tools like NoMAD and Apple’s Enterprise Connect, it’s become more challenging to identify which people are logged into which computers. While mobile Active Directory accounts will use the username and password of the person’s AD account, there is no such certainty with local user accounts.

Fortunately, my colleague Joe Chilcote recently let me know that it’s possible to query the logged-in user’s login keychain and get the username of the Active Directory account which is logged into Enterprise Connect. This can be accomplished by running the following command as the logged-in user:

/usr/bin/security find-generic-password -l "Enterprise Connect" $HOME/Library/Keychains/login.keychain | awk -F "=" '/acct/ {print $2}' | tr -d "\""

That should produce output similar to that shown below:

computername:~ username$ /usr/bin/security find-generic-password -l "Enterprise Connect" $HOME/Library/Keychains/login.keychain | awk -F "=" '/acct/ {print $2}' | tr -d "\""
AD_username_here
computername:~ username$

It’s also possible to leverage this technique to update the User and Location section of a particular computer managed by a Jamf Pro server. For more information, see below the jump.

I’ve written a script which is designed to the following:

1. Identify if Apple Enterprise Connect is installed on a particular Mac
2. If Enterprise Connect is installed, identify the username of the Active Directory account logged into Enterprise Connect.
3. Upload the username information to a Jamf Pro server and update the User and Location section of the computer’s inventory listing.

The script is available below. It is also available on Github at the following address:

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/Casper_Scripts/update_jamf_pro_user_inventory_using_apple_enterprise_connect_credentials

If you want to run this script from your Jamf Pro server, it should be set up as follows:

One way to use the inventory update capability would be to set up a policy which runs the script, where the policy is triggered by a user logging in to the Mac.

As part of the release of Office 2016 15.33.0, a number of managed preference options have been added and some have changed from what they were before. An example of one that has changed is the DefaultsToLocalOpenSave management setting, which sets the Open and Save options in Office 2016 apps to default to On My Mac instead of Online Locations.

In Microsoft Office 2016 15.32.x and earlier, the  DefaultsToLocalOpenSave setting could only be managed by running a command similar to the one below on the individual user accounts:

/usr/bin/defaults write "/path/to/user/homefolder/Library/Group Containers/UBF8T346G9.Office/"com.microsoft.officeprefs DefaultsToLocalOpenSave -bool true

To set this for all accounts on a particular Mac, I had written the following script:

As of Microsoft Office 2016 15.33.x, this setting can now be set at the global level for all users by running the following command with root privileges:

/usr/bin/defaults write /Library/Preferences/com.microsoft.office DefaultsToLocalOpenSave -bool true

I’ve posted an updated script for manage this setting to GitHub, available via the link below:

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/set_office_2016_default_save_option_to_on_my_mac

This setting can now also be managed with a profile, so I’ve created a .mobileconfig file and posted it here on Github:

https://github.com/rtrouton/profiles/tree/master/Office2016DefaultToLocalSave

A number of session videos (including mine) have been posted from MacAD UK 2017. For those interested, the videos are available on YouTube via the link below:

https://www.youtube.com/playlist?list=PLe6gxSMzV0S9JhDowmWNSGesQ16F_ZmUB

For convenience, I’ve linked my session here.

As part of a project I’m working on, I needed to set up a cloud distribution point for a Jamf Pro server in Amazon Web Services. AWS -hosted cloud distribution points use a bucket in Amazon’s S3 service to store the files hosted by the distribution point. To help secure the S3 bucket, I enabled S3 server-side encryption. This encryption provides data at rest protection for files stored in a S3 bucket and is managed by Amazon’s S3 service.

Once that security was enabled, I was unable to then upload either installer .pkgs or .dmgs to the S3 bucket associated with the cloud distribution point using any of the following methods:

• Web console package upload
• Casper Admin
• AutoPkg using JSSImporter

The unusual part was that the installer would look like it would upload and appear as a valid package when viewed from the Jamf Pro web console.

However, if I viewed the S3 bucket from the AWS console, the actual installer files would not be present in the S3 bucket.

For more details, see below the jump.

To address this issue, I opened a support call with Jamf support. While working with Jamf, I discovered that if I removed the encryption policy options from the S3 bucket policy, I was able to upload to the S3 bucket again.

Uploads blocked with this policy applied:

{
    "Version": "2008-10-17",
    "Id": "PolicyForCloudFrontPrivateContent",
    "Statement": [
        {
            "Sid": "DenyIncorrectEncryptionHeader",
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::jamfd880e2e8b5774d2382ffde1009852f78/*",
            "Condition": {
                "StringNotEquals": {
                    "s3:x-amz-server-side-encryption": "AES256"
                }
            }
        },
        {
            "Sid": "DenyUnEncryptedObjectUploads",
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::jamfd880e2e8b5774d2382ffde1009852f78/*",
            "Condition": {
                "Null": {
                    "s3:x-amz-server-side-encryption": "true"
                }
            }
        },
        {
            "Sid": " Grant a CloudFront Origin Identity access to support private content",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity AA9F007AA023464E"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::jamfd880e2e8b5774d2382ffde1009852f78/*"
        }
    ]
}

Uploads work with this policy applied:

{
    "Version": "2008-10-17",
    "Id": "PolicyForCloudFrontPrivateContent",
    "Statement": [
        {
            "Sid": " Grant a CloudFront Origin Identity access to support private content",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity AA9F007AA023464E"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::jamfd880e2e8b5774d2382ffde1009852f78/*"
        }
    ]
}

With the encryption policy options removed, I confirmed that I could now upload to the cloud distribution point and have the files appear in the S3 bucket.

The support engineer I worked with confirmed that Jamf does not support using S3 server-side encryption at this time and asked me to open a feature request. I’ve now opened a feature request, available via the link below:

https://www.jamf.com/jamf-nation/feature-requests/6016/support-requested-for-s3-server-side-encryption-for-jamf-pro-cloud-distribution-points-hosted-in-amazon-web-services

If you need to have S3 server side encryption enabled on your S3 buckets, please vote it up.

While working on a project involving Amazon Web Services, I ran across the concept of being able to use temporary credentials with AWS’s Command Line Interface (awscli) tool. When using the awscli tool, it is necessary to provide authentication credentials so that the aws tool is able to authorize its actions with AWS. When running the awscli tool on an EC 2 instance, AWS has provided a way to get temporary authentication credentials on demand, through the use of IAM roles.

In my research on the topic, I found a lot of posts showing how to use temporary credentials, but not a lot of information on how to set up the needed IAM roles. After some additional research, in addition to trial and error, I was able to figure out the IAM role setup process. For more details, see below the jump.

Creating an IAM Role

1. Log into the AWS console

2. Select IAM, under Security, Identity & Compliance

3. In the IAM window, select Roles.

4. In the Roles window, click on the Create New Role button.

5. To enable a role for EC2 instances, click the Select button for Amazon EC2.

6. Locate a policy that does what is wanted (the list will include Amazon-provided policies, as well as giving access to ones written by your customer account.) In this case, I want to find policies that give me full rights to Amazon S3 buckets.

7. Once the policy is located, check the box for the policy then click the Next Step button.

8. Name the role and put in a description of what the role is supposed to do. Once finished, click the Create Role button.

9. The newly-created role should now appear in the list of available roles.

Associate IAM Roles with EC2 instances

To associate a role with an EC2 instance at the time of the instances’ creation, select the role from the IAM role section of the Configure Instance Details window.

To add a role to an already-running instance, use the following procedure:

1. Select the instance in question

2. Click on the Actions button, then select Instance Settings: Attach/Replace IAM Role

3. Select the role you want to associate with the instance, then click the Apply button.

4. If the role applies successfully, a success message should appear. Click the Close button.

5. The role should appear associated with the EC 2 instance.

Using IAM roles for temporary credentials

Once an EC2 instance has been associated with a role, it should now be able to access temporary authentication credentials for use with the awscli tool and other applications which can use AWS credentials. These temporary credentials will allow the awscli tool to automatically request credentials from AWS for tasks that the role’s policy or policies allow access to.

For tools which cannot get automatic access to AWS credentials, it is possible to retrieve credentials from AWS using the curl command. In order to get the credentials, you will first need to identify the name of the role associated with the EC2 instance. This can be done by running the following command from inside the EC2 instance:

curl http://169.254.169.254/latest/meta-data/iam/security-credentials/

Once the role name is available, you can reference it in the following command:

curl http://169.254.169.254/latest/meta-data/iam/security-credentials/role_name_goes_here

This will pull the credentials from AWS and display them.

The usual credentials that are needed by tools are the AccessKeyID and SecretAccessKey values. The date and time of the credentials’ expiration are also listed.

The AccessKeyID and SecretAccessKey values can be extracted by themselves by using the following commands:

AccessKeyID:

curl http://169.254.169.254/latest/meta-data/iam/security-credentials/role_name_goes_here | awk '/AccessKeyId/ {print $3}' | sed 's/[^0-9A-Z]*//g'

SecretAccessKey:

curl http://169.254.169.254/latest/meta-data/iam/security-credentials/role_name_goes_here | awk '/SecretAccessKey/ {print $3}' | sed 's/[^0-9A-Za-z/+=]*//g'

I recently needed to configure Jamf’s Jamf Infrastructure Manager (JIM) to provide a way for a Jamf Pro server hosted outside a company’s network to be able to talk to an otherwise inaccessible Active Directory domain.

The documentation on how to set up an Infrastructure Manager covers the essentials of how to do it, but doesn’t include any screenshots or have information about how to access the logs to help debug problems. After some research and working with the JIM a bit, I was able to figure out the basics. For more details, see below the jump.

The JIM officially supports the following OSs:

• Ubuntu 14.04 LTS Server (64-bit) or Ubuntu 16.04 LTS Server (64-bit)
• Red Hat Enterprise Linux (RHEL) 7.0, 7.1, or 7.2
• Windows Server 2008 R2 (64-bit), Windows Server 2012 (64-bit), or Windows Server 2012 R2 (64-bit)

In this example, I’m going to be setting the JIM up on RHEL.

Installing the JIM

Pre-requisites:

• Supported operating system
• Otherwise unused network port higher than 1024 opened inbound, both on the firewall and on the machine hosting the JIM
• Ports opened from the machine hosting the JIM to your Active Directory domain. Usually, this means allowing inbound access to an AD domain controller via either port 389 (for unencrypted LDAP communication) or port 636 (for encrypted LDAP communication)

1. Download the JIM .rpm installer file from your Jamf Nation assets list (for RHEL, this is listed as the Infrastructure Manager Installer for Linux.)

2. Copy it to a convenient place on the server you want to install the JIM on.

3. Log in to the server as a user with superuser privileges.

4. Run the JIM installer by using a command similar to the one shown below with root privileges:

sudo rpm -i /path/to/jamf-im-1.3.0-1.noarch.rpm

5. Once the installation process has completed, you’ll be prompted to enroll using the following command:

sudo jamf-im enroll

As part of the enrollment process, you’ll be prompted for four settings:

• Jamf Pro URL (for example: https://jamfpro.company.com)
• Jamf Pro user account with the Infrastructure Manager privilege (for example, your admin account)
• Password to the Jamf Pro user account
• Hostname of the machine you’re installing it on. (This must be the fully qualified domain name of the machine.)

Note: The hostname of the machine must resolve both for the machine hosting the JIM and for the remote Jamf Pro server, so there can’t be mismatches like having the machine itself think its hostname is blahblah.int.company.com and the remote Jamf Pro server think its hostname is blehbleh.ext.company.com.

6. Once configured, the JIM process will restart and enroll itself with the remote Jamf Pro server.

7. To verify the enrollment succeeded, log into the remote JSS and go to Management Settings: Server Infrastructure and click on Infrastructure Managers.

8. In the Infrastructure Managers window, you should see a listing for the enrolled JIM.

9. To check the JIM enrollment status, click on the listing.

Using the JIM as an LDAP Proxy

If you already have the settings configured for the Active Directory domain, enabling the JIM to act as an LDAP proxy is fairly straightforward.

1. Go to Management Settings: System Settings and click on LDAP Servers.

2. Click on the listing for your Active Directory domain settings.

3. In the Active Directory domain settings, click the Enable LDAP Proxy Server checkbox.

4. In the Proxy Server drop-down menu, select the hostname of the enrolled JIM.

5. Set the port number of your inbound port.

Note: The port number specified here must be the same port number which is opened in the firewall and on the machine hosting the JIM. The JIM is not able to listen to alternate ports and the Jamf Pro server tells the JIM which port it needs to be listening on. This means that you will not be able to open one port in your firewall, but have the JIM listen at a different port.

6. Once your proxy settings are entered, save your changes.

Advisory: It is not currently possible to use the LDAP Proxy as part of the Microsoft’s Active Directory assistant in Jamf Pro. If the settings for your Active Directory domain have not been configured previously, you will need to use the Configure Manually option to set up your AD domain settings and domain mappings.

Verifying connection to the Active Directory domain

Once the LDAP proxy is in place, you can verify if it is working by using the Test button in the Active Directory domain settings.

1. Open the Active Directory domain settings.

2. Click on the Test button.

3. In the Test window, select User Mappings.

4. Enter a username to look up, then click the Test button.

5. If all goes well, a listing for the username should be returned.

6. Repeat lookups as needed for User Group Mappings and User Group Membership Mapping.

Accessing JIM logs

If all didn’t go well, you may need to check the JIM logs on the JIM’s host machine to see what’s going on. Those logs are available in the following location on Red Hat Enterprise Linux:

• /var/log/jamf-im-launcher.log
• /var/log/jamf-im.log
• /var/log/jamf-im-pre-enroll.log

When writing scripts, it’s sometimes useful to be able to be able to include and deploy binary files as part of the script run. An example of this would be if you want to use MySQL 5.6 and later’s option for creating a MySQL connection file. This is a file that allows you to store MySQL authentication inside an encrypted file named .mylogin.cnf.

Rather than trying to script the creation of a MySQL connection file, where the creation process would involve placing the MySQL authentication credentials in a readable format inside the script, it is easier and more secure to build the connection file manually on one machine and then encode the encrypted MySQL connection file into ASCII text using base64 encoding. Once encoded, the ASCII text can be decoded as part of a script designed to deploy the still-encrypted MySQL connection file to a desired location.

For more details on how to use base64 encoding, please see below the jump.

To encode files, you can use the openssl utility’s base64 function to encode them as ASCII characters. For example, a file named hello_world.txt with the following contents needs to be copied to the same location on multiple Macs:

--------

Hello, World!

---------

To encode the file, run the following command:

openssl base64 < /path/to/hello_world.txt

That will give you a ASCII string like that shown below:

LS0tLS0tLS0KCkhlbGxvLCBXb3JsZCEKCi0tLS0tLS0tLQo=

You can then embed the string in a script and have it read back into a new file. For example, the script shown below will decode and store a copy of the hello_world.txt file inside the /Users/Shared directory:

#!/bin/bash

# Decode hello_world.txt stored in base64 format
# and store it as /Users/Shared/hello_world.txt.

openssl base64 -d <<HELLOWORLD > /Users/Shared/hello_world.txt
LS0tLS0tLS0KCkhlbGxvLCBXb3JsZCEKCi0tLS0tLS0tLQo=
HELLOWORLD

Running the script on the desired machines will allow the hello_world.txt file to be deployed into the desired location inside the /Users/Shared directory.

As files get larger, the block of ASCII text will also grow. Encoding the script shown above will produce a block of ASCII text that looks similar to this:

IyEvYmluL2Jhc2gKCiMgRGVjb2RlIGhlbGxvX3dvcmxkLnR4dCBzdG9yZWQgaW4g
YmFzZTY0IGZvcm1hdCAKIyBhbmQgc3RvcmUgaXQgYXMgL1VzZXJzL1NoYXJlZC9o
ZWxsb193b3JsZC50eHQuCgpvcGVuc3NsIGJhc2U2NCAtZCA8PEhFTExPV09STEQg
PiAvcGF0aC90by9oZWxsb193b3JsZC50eHQKTFMwdExTMHRMUzBLQ2tobGJHeHZM
Q0JYYjNKc1pDRUtDaTB0TFMwdExTMHRMUW89CkhFTExPV09STEQK

This encoding technique can also be used to deploy entire executable binaries, where the program in question is encoded using the technique described above, then deployed to a desired location.

I’ll be speaking at MacDevOpsYVR 2017, which is taking place in Vancouver, Canada from June 5th – 6th, 2017. My session will be an overview of Apple’s past and present filesystems, with an introduction to Apple File System (APFS) and a discussion of its current state of development.

You can see the entire list of speakers at https://www.macdevops.ca/speakers/

The same week that I’ll be speaking at MacDevOpsYVR 2017, I’ll also be speaking at MacDeployment 2017:

MacDeployment is taking place in Calgary, Canada from June 8th – 9th, 2017. My session will be an overview of Apple’s past and present filesystems, with an introduction to Apple File System (APFS) and a discussion of its current state of development.

You can see the entire list of speakers at http://macdeployment.ca/speakers

As part of an ongoing project, I needed to set up a new Apple VPP account for use with a test environment. The reason I did this was that I didn’t want to cause conflicts with our production VPP account. When I went to set up the account though, I ran into an interesting problem.

As part of the VPP account setup, I needed to provide a DUNS number. However, the DUNS number I had belongs to a company based outside of the US and Apple’s US VPP enrollment site would only accept DUNS numbers associated with US addresses. Instead, I needed to use the DUNS number for my company’s US subsidiary in place of the DUNS number that I had. The problem was that I had no idea what that DUNS number was.

After some research, I found a way to look up the DUNS number I needed and was able to successfully register my test environment’s VPP account with Apple. For more details, see below the jump.

Dun & Bradstreet, the company which runs the the DUNS system, provides a way to look up DUNS numbers on their website. To use this lookup, use the procedure shown below:

1. Go to http://www.dnb.com/duns-number/lookup.html

2. Go to Search By Company Name

3. Enter your company information, check the I’m not a robot checkbox, then click the Search Now button.

For example, here’s how to use this to find Walmart‘s DUNS number. I looked up the address of Walmart’s corporate headquarters in Benton, Arkansas and did a search using that.

The site gave me several options to choose from and I picked the most likely one, based on the address and phone number information I had for Walmart.

I was requested to enter an email address, to have the DUNS information emailed to me.

Shortly afterwards, I received an email with the appropriate DUNS number.

When deploying Macs for use in classrooms or for training, there is occasionally a requirement that certain applications must be blocked from running. Usually, this is to make sure that the student or test taker using the Mac is not able to use the blocked applications because it would distract them or otherwise cause problems.

On iOS, there is a way to do this via the blacklistedAppBundleIDs key available in the Restrictions payload. However, this key is not available on macOS and Macs will ignore the blacklist.

On macOS, there is the ability to set an application whitelist via Profile Manager but not a blacklist.

However, the profile specification does include the ability to configure an application blacklist using the pathBlackList key in the settings managed by the com.apple.applicationaccess.new payload.

For more details, see below the jump.

Since the ability to set an application blacklist for macOS is currently missing from Profile Manager, a profile to blacklist application may need to be manually created. See below for an example profile which blacklists the following applications:

/Applications/Chess.app
/Applications/FaceTime.app
/Applications/Mail.app
/Applications/Messages.app

Note: In addition to setting the application blacklist, a correctly-built profile will need to include whitelist entries that explicitly allow all other applications other than the ones being blacklisted.

When setting an application blacklist using the profile, one thing to be aware of is that the blacklist can be overridden by an administrator account.

If an administrator chooses, they can set the application block to be overridden once or permanently.

For those who want to block applications using a management profile, I’ve created an example .mobileconfig file and posted it here on Github:

https://github.com/rtrouton/profiles/tree/master/BlacklistApplications

Jamf Pro-managed Macs usually have a management account on the Mac, which is normally created as part of the Mac’s enrollment in the Jamf Pro service. This may cause issues in some Mac environments, where the creation of local user accounts is tightly controlled to help minimize opportunities for malicious third parties to compromise unused accounts.

To help protect against the Jamf Pro management account being compromised, Jamf has added some protections. These protections include including the ability to set a random password for the account on a per-machine basis and the ability to rotate the password on a regular basis.

Depending on your needs though, it is also possible avoid setting up the Jamf Pro management account on Macs. The reason for this is that the Jamf Pro agent by and large does not need the Jamf Pro management account in order to work properly.

As of Jamf Pro 9.99.0, the Jamf Pro management account is used for the following:

• To provide SSH connectivity for Jamf’s Remote application
• To provide the option of enabling the management user account for FileVault 2

If you are not using Jamf’s Remote application for remote screen sharing, or enabling the Jamf Pro management account for FileVault 2, it is not necessary to install the Jamf Pro management account on Jamf Pro-managed Macs at all. For more details, see below the jump.

The usual method of enrolling a Mac into Jamf Pro uses a QuickAdd installer package, generated by Jamf’s Recon application or via user-initiated enrollment.

Here’s how you can configure Recon to generate a QuickAdd package that does not install the Jamf Pro management account:

1. Launch Recon
2. Select QuickAdd Package
3. Specify the name of the management account you want to use

4. In the Method for Setting Password: drop-down menu, select Randomly generate password.

This will cause two things to happen in the Recon interface.

A. The Create management account if it does not exist option will be enabled

B. The Create… button in the lower-right corner will go from grayed-out to active.

5. Uncheck the Create management account if it does not exist option

This will cause the In the Method for Setting Password: drop-down menu to display Specify password… , but the Create… button in the lower-right corner will remain active.

6. Set any other desired options.

7. Click the Create… button

The Recon application will generate a QuickAdd package that will enroll the Mac in the appropriate Jamf Pro server, but the newly-created QuickAdd will not create the Jamf Pro management account on the Mac as part of the installation process.

Note: The computer will still appear in the Jamf Pro server’s inventory as a managed computer with the management account listed.

The same method can used with user-initiated enrollment. To set the QuickAdd packages generated by the user-initiated enrollment process to not create the management user account, use the following procedure:

1. Log into your Jamf Pro server.
2. Go to Management Settings: Global Management and select User-Initiated Enrollment

3. Under Platforms: macOS, uncheck the Create management account setting.

Note: There is no need to change the Method for Setting Password or Password Length settings.

I’ve been doing a lot of work recently with Linux VMs that are hosted on Amazon Web Services‘ EC2 service. As part of this work, I’ve been working on two problems in parallel:

• Enabling automation of certain management commands for the VMs
• Securing SSH

Part of the issue was that I thought I needed to have SSH available to enable remote administration. If that was true, I also needed to secure SSH access so that I could use it and malicious third parties couldn’t. However, whatever method I chose also needed to be easily accessible to my team so that they could access the AWS-hosted VMs in case of an emergency where I wasn’t available.

I went through a few iterations of SSH solutions, including investigating multi-factor authentication and setting up SSH bastions. In the end though, I discovered a surprising solution that fixed both of my problems: AWS’s EC2 Systems Manager

Systems Manager allowed me to do the following:

1. Manage my Linux VMs on EC2 without using SSH
2. Block SSH access on my Linux VMs
3. Run commands on multiple VMs at once
4. Create a library of frequently used tasks and run those commands without needing to re-enter the scripts used to run those tasks.
5. Not spend extra money on a management solution because AWS makes Systems Manager available at no cost to AWS customers.

For more details, please see below the jump.

To get started with EC 2 Systems Manager, the first thing you need to do is create an IAM role that you can associate the following policy with:

AmazonEC2RoleforSSM

This AWS policy enables an EC2-hosted instance to communicate with Systems Manager.

Note: If you have an existing role associated with your EC2 instance, you can add the AmazonEC2RoleforSSM policy to that existing role.

Once you have your IAM role created, it needs to be associated with the instance. This can be done by either:

A. Assigning the role to the instance at the time of the instances’ creation

B. Assigning the role to an existing instance.

Once the role is associated with the appropriate instances, the next thing to do is install the Systems Manager agent on the EC2 instance. Once all the needed role and agent setup work is done, your VMs in a particular AWS region should register themselves with the EC2 Systems Manager for that region and you should be ready to go.

To access EC2 Systems Manager, please use the procedure shown below:

1. Log into the AWS web console

2. Select EC2

3. Select Managed Instances

A list of all managed instances for that AWS region will be displayed.

To see more detailed information, click on an instance.

To see inventory information, click on the Inventory tab.

Running commands

To run commands on an instance, use the procedure shown below.

1. Select the Run a command button.

2. Click the AWS-RunShellScript selection.

3. Select one or more instances.

4. Enter the command you want to run.

For this example, the uptime command is being run.

5. Once the command is entered, click the Run button.

6. If the command succeeded, you will see a Success message. To view the command’s run, click the link on the status message.

7. You’ll be taken to a command list that’s been filtered to just show that command. To see the result of the command, click the Output tab.

8. Under the Output tab, click the View Output link.

The output of the command is shown in a new window.

Note: The output available here is limited to 2500 characters.

9. Once finished viewing the command output, click the Close button.

In addition to commands, you can also run shell scripts in the Commands entry.

To build a library of commands to run, you can use EC2 Systems Manager Documents. These are JSON files that can be used to run commands, including Unix shell scripts. As an example, please see below for two Systems Manager Documents that I created for managing Jamf Pro’s Tomcat:

Stop Jamf Pro Tomcat EC2 Systems Manager Document:

Restart Jamf Pro Tomcat EC2 Systems Manager Document:

Both of these Documents are available on GitHub via the links below:

https://github.com/rtrouton/ec2_systems_manager/tree/master/restart_jamf_pro_tomcat

https://github.com/rtrouton/ec2_systems_manager/tree/master/stop_jamf_pro_tomcat

For those who wanted a copy of my filesystem talk at the MacDevOpsYVR 2017 conference, here are links to the slides in PDF and Keynote format.

PDF – http://tinyurl.com/MacDevOpsYVR2017pdf

Keynote – http://tinyurl.com/MacDevOpsYVR2017key

For those who wanted a copy of my payload-free package QuickTalk at the MacDevOpsYVR 2017 conference, here are links to the slides in PDF and Keynote format.

PDF – https://tinyurl.com/MacDevOpsPkgPDF

Keynote – https://tinyurl.com/MacDevOpsPkgKey

For those who wanted a copy of my filesystem talk at the MacDeployment 2017 conference, here are links to the slides in PDF and Keynote format.

PDF – http://tinyurl.com/MacDeployment2017pdf

Keynote – http://tinyurl.com/MacDeployment2017key