I'm deploying shared printers to macOS users over IPP. When users print through the macOS graphical interface, they're prompted for credentials every time, but jobs submitted with the lp command from Terminal print successfully without a prompt.
I'd rather not have users save their passwords in Keychain because password changes can cause stale-credential problems. Ideally, macOS would use Kerberos/Negotiate automatically through the deployed Kerberos profile. The Macs are managed with Intune and aren't domain-joined, although they do have a Kerberos configuration profile.
I've already tried setting `lpadmin -p PRINTERNAME -o auth-info-required=negotiate` and `cupsctl DefaultAuthType=Negotiate`, but neither changed the behavior. Has anyone diagnosed or fixed this kind of GUI-versus-command-line authentication difference?
4 Answers
This can also be tied to a macOS release-specific bug. Updating to the newest supported release is worth testing, especially if IPPS or a print-management integration is involved. A later macOS update resolved a similar authentication issue for another deployment, although their setup used PaperCut and a different device-management platform.
It may be worth evaluating a print-management platform such as PaperCut. It adds cost, but it can handle authentication and printer deployment more consistently than relying on each macOS endpoint’s CUPS behavior.
One practical alternative is to host the queues on a Windows print server instead of relying directly on CUPS on the Macs. In at least one environment, authentication worked more reliably that way.
Check `/var/log/cups/error_log` immediately after reproducing the prompt. Temporarily enable verbose logging with `cupsctl --debug-logging` so you can see whether CUPS is attempting Negotiate/Kerberos or going straight to credential authentication. Those point to different fixes.
Also verify that the print server has the correct HTTP service principal name in Active Directory. IPP over Kerberos generally needs an SPN such as `HTTP/printserver.fqdn@REALM`; a regular host record alone may not be enough. On the Windows side, `setspn -L ` can confirm what is registered.
The HTTP SPN is already configured, but I’ll inspect the CUPS logs. I don’t think the ticket is completely unavailable because browsing directly to the site doesn’t prompt for credentials, and curl shows a WWW-Authenticate response with a usable Kerberos key.
I looked into that, but our existing printing setup is stable. The goal is mainly to add Mac support without introducing a larger print-management system.