Archive

A while back, I had set up the Jamf Infrastructure Manager (JIM) in a VM running Red Hat Enterprise Linux (RHEL) 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 JIM software has been running fine since I configured it, but I recently needed to take a look at the JIM logs as part of diagnosing another issue.

For those not familiar with the JIM software, it has several log files and those logs are available in the following location on RHEL:

When I checked the logs, I noticed that /var/log/jamf-im.log had grown to almost 500 MBs in size.

Considering this log is a plaintext file, that’s a big log file and it seemingly had been not been rotated or otherwise changed since I first installed the JIM software. To help make sure that the host VM would not eventually run out of space because of this growing log file, I needed to implement log rotation for the JIM logs. For more details, see below the jump.

Like this:

As part of my Jamf Pro testing process, I will often set up a VM using a production setup workflow then enroll that newly-setup VM into my test Jamf Pro server. However, as part of my production workflow setup, I will usually install my CasperCheck self-repair solution in order to make sure the machine stays enrolled with my Jamf Pro server.

Unfortunately, this can lead to the following chain of events:

Test VM is enrolled in the test Jamf Pro server

CasperCheck runs on its pre-set schedule and detects that it is not enrolled with the Jamf Pro server specified in the script.

CasperCheck runs its repair functions and enrolls the test VM in the production server.

I wonder why my test VM isn’t talking to the test Jamf Pro server.

I check the CasperCheck log, grumble when I notice that CasperCheck has done its job, and then install the test server’s CasperCheck script on the test VM.

Reboot the test VM to trigger the test server’s CasperCheck script to enroll the test VM into the test server again.

This situation happened infrequently enough in the past that I usually just dealt with it on an individual basis, but I finally decided to fix it by writing a Jamf Pro Extension Attribute to help me identify which Jamf Pro server was specified in the installed copy of CasperCheck . For more details, see below the jump.

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:

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.

Like this:

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.

Like this:

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:

Like this:

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.