Categories
MacAdmin

SMB Printing on macOS Without Active Directory Binding


The tale of two hostnames

In May 2024, I was assisting a school with setting up a new macOS deployment workflow.

They were previously an all-Windows school and were looking to pilot macOS devices.

Everything went smoothly except for one key issue:

The Mac couldn’t print.

More specifically, the Mac couldn’t print to their SMB printer queues shared/managed by Papercut.

Whilst the official recommendation from Papercut when experiencing SMB issues post PrintNightmare is to use LPD or Mobility Print (IPP/HTTP), sometimes you have to deal with the cards that are dealt 🙂 

https://papercut.com/support/known-issues/?id=PO-522#ng

As described above, the symptom I saw was:

…when printing macOS > Windows over SMB… can result in printers going into a Waiting state indefinitely. You might initially see them go into a Hold for Authentication state - if you click refresh and supply valid credentials, you will end up in the Waiting state.

One of the suggestions in the above thread was to add ?encryption=no to the print queue, which on its own didn’t make any difference.

The baffling part of the issue was that printing WORKED in my initial testing but stopped when I was minting the workflow ready to handover to them.

So what had changed?

I had added a computer naming step to the workflow.

The script used to name the device resembled this:

ScriptRepo/ComputerName-Set-Serial.sh at master · aarondavidpolley/ScriptRepo · GitHub

Changing the computer name in System Settings/Preferences didn’t fix the issue.

Resetting the device, not using the script to name the computer: WORKED!

So why did setting the computer name break it?

If you pay close attention to the script above, macOS has three names:

  • ComputerName
  • HostName
  • LocalHostName

When you use the built-in directory binding plugin (via script or directory utility), the HostName is important to be set before binding as it forms part of the information used in the domain join.

The HostName can be different to the visible name of the computer in Terminal, System Settings, etc., which is why admins have been using scutil for a while to set all three in scripts.

The Jamf binary on a Jamf Pro managed Mac uses the same approach of setting all three names when you use it to set the computer name.

In a world that is ever increasingly free of AD-Bound Macs (to which we rejoice), setting all three computer names is less important and evidently troublesome when trying to print to SMB queues hosted on Windows Server.

Looking at logs, network traffic, and digging around the web, there is evidence that deep in macOS is code that looks for the HostName being set as evidence of an AD-Bound device.

As a result of this confused state of identity, it starts sending RPC signals that AD/Windows Server doesn’t know what to deal with, causing the communication to fail.

Computer: “Hey, I’m this AD-Bound device MAC123, can I print?”

Server: “MAC123 not found in my directory. Go away.”

End of print job attempt.

At the time of this discovery, naming the computer was not an important success criterion.

We skipped naming the device, configured the printer queue install (using a script similar to the one below), that included the ?encryption=no in the queue URI, tested successfully, and off we rode into the sunset.

ScriptRepo/Printers-CUPS-Add-Printer.sh at master · aarondavidpolley/ScriptRepo · GitHub

So why bring this up in September 2025?

I recently visited that same school and helped them revise their macOS deployment workflow. They wanted to expand the pilot to a new set of users and add in any latest tooling/config changes that were appropriate.

Printing came up again.

The papercut environment was largely unchanged, but the queues had stopped working.

After troubleshooting and dusting off old notes (and brain cells), I was able to conclude:

  1. macOS 15.6+ has the same issues as previous versions (including macOS 14, where I had encountered the year prior).
  2. Jamf Setup Manager, which I was now using to set the computer name and therefore using Jamf Pro’s Jamf Binary, was setting all three computer names, repeating the hostname/RPC issue.
  3. Using a script to run scutil --set HostName “” and then rebooting the machine will fix the RPC authentication issue.
  4. The ?encryption=no string now causes the print job to fail and needs to be removed from the printer queue path.
  5. Using a script to only set the LocalHostName and ComputerName via scutil works fine (and is effectively the same as setting the computer name in System Settings).

So in summary:

Symptom: If you can’t print to an SMB printer queue hosted on a Windows Server and it gets stuck waiting or on hold for authentication (even though you’ve provided user auth credentials or have Kerberos tickets).

Check: run scutil --get HostName and see if you get a result.

Fix: if the HostName has been set, run scutil --set HostName “” and then reboot the Mac to fix the RPC authentication issue. 

Hope you find this and it assists your obscure printing issue 😆

Categories
MacAdmin

MDM Managed Administrator Account

The tale of the macOS MDM Managed Local Administrator Account vs Jamf Management Account

Over the years as Jamf Pro and macOS have evolved, from pre-MDM framework, including the Casper Suite days, to the more recent evolutions of FileVault and SecureToken, Apple is investing more and more into “non-agent” frameworks to build on the Success of an MDM first approach in iOS.

Jamf Pro has been a fantastic tool for running policy and agent/binary based to fill in the gaps for where MDM framework initially didn’t existing, and then subsequent in its short comings.

The next low hanging fruit in both Apple and Jamf Pro’s evolution, around local macOS account management, is the macOS local administrator account.

Apple have recently clearly defined the future role of the “managed administrator account” that the MDM framework can remotely manage:

https://support.apple.com/en-au/guide/mdm/mdmca092ad96/web

Jamf Pro currently has a partial implementation of the “managed administrator account” as part of macOS PreStage Enrollment, however there currently is no ongoing “stateful” management of the account.

Jamf Pro does currently have a process of managing the password of Jamf Pro Management Account found in User-Initiated Enrolment using the Jamf Pro binary via policies.

A recent release of Jamf Pro better separated the MDM created PreStage enrolment account and the Jamf Management Account, however, the Jamf Management Account framework is largely one of Technical Debt in the Jamf Pro Framework.

2 Possible pathways forward:

  1. Migrate the Jamf Pro Management account out of policy/binary based management and assume the role of Apple’s “managed administrator account”. Some of the related Jamf Admin functions will need to be deprecated and some replaced by modern MDM features such as MDM enabled Apple Remote Desktop management
  2. Build out the MDM commands/framework for ongoing management of Apple’s MDM “managed administrator account” and mark the Jamf Management Account as deprecated. This would also involve replacing the Jamf Management account under UIE with the MDM “managed administrator account” for consistency across “Device Enrolment” and “Automated Device Enrolment” intended for corporately owned devices. User enrolment channel being developed by Apple will not have any management account in scope.

Which ever pathway is chosen, the messaging to Jamf Pro administrators in the community will be to move the primary corporate admin account account on corporately owned shared and one to one macOS devices to the MDM MDM “managed administrator account” and have a place on the Jamf Inventory Record to manage the password of the account as part of MDM commands and/or inventory data.

Similar to the concept of FileVault PRK and IRKs, I envision Jamf Administrators having the ability choose a common password across all devices, configured in one place, opted in as a default option on all macOS devices, with alternate options for individually specified and individually auto generated (ie LAPS concept) passwords on each computer inventory record. Auto generated, unique per machine, as found as an option with the Jamf Management account currently, should be a global option for the MDM “managed administrator account”.

The direction from Apple is clear and the technical debt of the Jamf Management account is confusing for many Jamf Administrators.

Here is a Feature Request I created before I turned it into a blog post (upvote away!):

https://www.jamf.com/jamf-nation/feature-requests/9590/macos-mdm-managed-local-administrator-account-vs-jamf-management-account

Here is a MacAdmins Community related discussion on the topic as well (non-Jamf specific):

https://twitter.com/wikiwalk/status/1275622118324162561

Categories
MacAdmin

JamfWATCH

Hi All.

After being at a recent Jamf course I was inspired to create a new project called JamfWATCH.  As per GitHub:

Jamf Pro WATCH Dog: Monitor and self heal Jamf Pro enrolment if framework is removed from a client computer

Basically, at both reactive and recurring intervals this tool checks if it can communicate with the Jamf Pro Server its supposed to be managed by and if senses an issue tried to repair itself. Great for scenarios where end users may have admin rights and decide to do silly things like remove management from their computer.

Check it out, test, and provide feedback!

https://github.com/aarondavidpolley/JamfWATCH

Categories
MacAdmin

JNUC 2016

Hi All,

As you may have seen I recently altered my web site to be more in line with my real day to day life, not just the music side; I am now “Musician & MacAdmin”. You can see my latest MacAdmin posts on the front page as well as my Music related items and news.

I just got back from JAMF Nation User Conference (JNUC) 2016 in Minnesota and I loved it. It was a great atmosphere for learning  and collaborating with our MacAdmin minds. My employer Max Computing sent me for which I am grateful.

Over the coming days I will try to post a summary of different sessions/events I enjoyed, but here is a top level summary

  1. The opening session(s) featuring CEO Dean Hager – he is an inspiring man and charismatic to say the least. The work he is personally doing in the social justic realm as well as help the JMAF Foundation do is remarkable and not common in corporations
  2. The renaming of the company from JAMF Software to “JAMF” to support product rebranding of Casper Suite and Bushel to JAMF Pro and JAMF Now respectively
  3. JAMF Patch Management – seeing the direction they were going and how it stacked against solutions like Munki
  4. Shopify’s Managing Devices in an Open Culture: great look at how their IT staff took a bunch of tech heads used to being the master of their own machine and convinced them that Mac Management was a good thing for them and the company
  5. The Mac@IBM presentations: truly an inspiring moment to see how they have become an Mac deployment in enterprise flagship
  6. Making Self Service a killer app from Paul Cowan of Waikato University in New Zealand
  7. User configuration framework: a great new tool developed for configuring apps and services at user login AND utilising sign on password for an SSO (single sign on) experience. https://github.com/alex030/UserConfigAgent
  8. Using SWIFT and the JSS API: great session as an early introduction to coding in SWIFT as well as how to do some basic functions for importing machine placeholders into the JSS (JAMF Software Server aka Casper aka JAMF Pro) for automating device enrolment
  9. Profiles: An IT Admins Best Friend; from the boys at dataJAR in the U.K. Hilarious and insightful it gave a great backbone understanding on managed preferences and how they have evolved plus some best practice

Overall it it was a great conference and I hope to share more soon. In the meantime you can check out the discussion links for each session and see if the slides have been posted:

https://www.jamf.com/jamf-nation/events/jnuc/2016/sessions