SMB Printing to Windows Print Server failing to connect to server suddenly

VintageMacGuy
Contributor II

Just this week, we are noticing that many Macs, but not all of them, are not able to print via our Windows print server. Nothing has changed on our Mac side.
We are printing via PaperCut, so using SMB on a printer installed via JAMF and no changes to the setup.
Macs not joined to the domain and not using the AD Username as the machine or profile name in many cases, but likely in many others.
I can add PaperCut LPD to the print server and print via LPD - but no authentication, so the job gets stuck with no way to get it to print from Papercut, unless the users profile on the Mac is named the same as their AD username.

The issue looks very similar to this one:
https://community.jamf.com/t5/jamf-pro/mac-printing-issue-after-microsoft-windows-print-server-updat...
However, we don't have the server updates referenced in the thread or PaperCut advisory.

Affected systems are running Monterey, Big Sur, and Catalina.
One Mac that was able to print, stopped printing immediately after upgrading from 12.1 to 12.2.
One Mac on 11.6.0 was printing yesterday, but stopped printing today. JAMF shows "ProfileList" updated just before it stopped working.
This is happening on both our Prod and Dev instances of JAMF.

Workarounds

I am able to set any Mac up to print straight to the printer using LPD protocol and the printer IP address with the correct driver.

If the user profile on the Mac is named after the AD profile, then I can use LPD to print to Papercut on the print server (after loading the PaperCut LPD service). Address: (IP or FQDN of print server), Queue: (PaperCut Printer Name).

My coworkers think it is JAMF "JAMF-ing up the Macs". But I can't see anything on the JAMF side that has done anything to the Macs, and no changes to printing have happened lately.

1 ACCEPTED SOLUTION

nstrauss
Contributor II

This is directly related to RPC changes in 12.2, 11.6.3, and Catalina security update 2022-001 (build 19H1713) in response to PrintNightmare. Nothing to do with Jamf or MDM in general. 😀 All of these have the patch Apple describes as...

"Resolves an issue that prevented authenticating to a Windows print server with increased RPC authentication level."

https://support.apple.com/en-us/HT212586

I'm curious to hear if you found it was resolved by switching to FQDN as the print queue URI. What were you using previously? smb://printserver/queuename? The only solution (which I hate) I've found is to turn off encryption with a URI parameter. For example, use smb://printserver.mydomain.com/queuename?encryption=no. Obviously not secure and not a long term solution. There's some anecdotal evidence the problem is with aliased URIs, but I don't have enough first hand knowledge to know if that's true. What version of Windows server are you running? Fully patched?

Apple is fully aware of the issue and collecting impact data from customers. If you have a support contract with them I'd ask you open a case. Feel free my reference my own open case 101616149128. The more customer impact data the better.

View solution in original post

57 REPLIES 57

I am seeing the same as chrisB - Once I get the machines (M1 or Intel) updated to 11.6.5 or 12.3.1 (presumably 12.3.0 also), I can create a new printer with the format:
smb://server.domain.com/PrinterName

And it starts printing again without causing a pause. 

abnaau
New Contributor III

We have a strange issue now. 
Kerberos needs ?encryption=no
Kerberos without gives "Unable to connect to printer"
UPN + password doesn't work. (username@domain.example.com)
REALM\username works (example: DOMAIN\username - This stopped working in january for unknown reasons)
REALM.fqdn\username doesn't work (DOMAIN.EXAMPLE.COM\username - But worked until 12.3)

Nothing makes sense. ...

matje84
New Contributor II

The weird thing is it starts working with Kerberos if you enable the Apple SSO plugin. No need to sign in, just have it enabled. With your feedback I tried to edit our NoMad configuration but without luck.

abnaau
New Contributor III

Do you have to deploy with correct domain settings or is a blank configuration profile enough? Any more info on this? 
I have a funny feeling that most with this issue don't have Jamf Connect installed in our environment and maybe that's why we only have a few cases.

matje84
New Contributor II

Yes, with the correct domain settings. For what I can see those are required when deploying a profile with the Single Sign-On payload.

abnaau
New Contributor III

The 12.3.1 update once again changed things.. This time the sporadic nature of the bug turned to: Everyone has the problem. 
Kerberos auth doesn't work  - basically everything needs ?encryption=no
Kerberos without gives "Unable to connect to printer"
UPN + password doesn't work. (username@domain.example.com)
REALM\username works (example: DOMAIN\username - This stopped working in january for unknown reasons)
REALM.fqdn\username doesn't work (DOMAIN.EXAMPLE.COM\username - But worked until 12.3)

Nothing makes sense. ... still... And again... Good news is I can troubleshoot on an arbitrary machine. 

abnaau
New Contributor III

Problem "solved". 

Add ?encryption=no

Set: AuthInfoRequired negotiate (for Kerberos)
Disable SMB multichannel
Don't use UPN for login (!?) 

bartzach
New Contributor II

Hi Abnaau,

Is it still working for you?

I tried just now on my test Mac and I am still getting "Unable to connect to printer".

I don't have access to server with printers so I tried to disable SMB multichannel locally by doing this:

If you want to fully disable SMB Multichannel support in macOS, add the following line to the /etc/nsmb.conf file:

mc_on=no

Source: https://support.apple.com/en-ie/HT212277

Cheers,

Bart

bartzach
New Contributor II

Ignore? I found out my customer has different spool that has the same printers installed. They did some maintenance on it last week and the other spool works without encryption=no and just with ad username and password. Happy days!

abnaau
New Contributor III

Sorry I missed your reply.
One year later - still an issue. I'm curious what kind of maintenance they did?
We still need this:
Add ?encryption=no

Set: AuthInfoRequired negotiate (for Kerberos)
Disable SMB multichannel
Don't use UPN for login (!?) 

Qwheel
Contributor II

We're currently going down the encryption=no route.
Due to the naming conventions of user accounts, we can't move to lpd:// so are stuck until Apple fix what they broke.
Our print supplier advised that the password remains obfuscated. It's just the username that isn't.
They suggested that printing had functioned this way for 20 years but platforms have decided to implement higher order encryption - hence why this hasn't been a problem in the past. (Do share if your supplier has told you otherwise :D)

I wrote some janky logic to go into our add printer script. Feel free to use it.

Downsides are - more logic will be required to re-enable encryption when Apple do fix what they broke. Continuing like this means the logic will have to stay until these OS's aren't in use anymore. 
You can also write some extension attributes to determine printer status (at the point of device Recon). Just to get an idea of how many devices are affected, or to echo out whether a device is currently affected.

I suspect all our lab devices will be affected by this in a couple of months. This is a big problem.

#!/bin/bash

#Check if Printer is already installed.
echo "Checking list of printers on the device..."
printername=$(lpstat -a | grep PrinterName | awk '{print $1}')
printername=`echo $printername | sed 's/ *$//g'`
ref="NameOfPrinter"

if [[ $printername == $ref ]]
then
	echo "Printer is already installed."
	echo "Skipping installation."
else
	echo "Printer doesn't exist on device."
	echo "installing Printer"

    #Gets the current MacOS version and splits it into variables.
    swVers=$(sw_vers -productVersion)
    swVersMajor=$(sw_vers -productVersion | awk -F '.' '{print $1}')
    swVersMinor=$(sw_vers -productVersion | awk -F '.' '{print $2}')
    swVersPatch=$(sw_vers -productVersion | awk -F '.' '{print $3}')
    swVersBuild1=$(sw_vers -buildVersion | cut -c1-3)
    swVersBuild2=$(sw_vers -buildVersion | cut -c4-8)

    #Fills the third item with a 0 if it's empty
    if [[ "$swVersPatch" == "" ]]; then
    swVersPatch="0"
    fi

    #Removes encryption for devices with MacOS 12.2 or later
    if [[ "$swVersMajor" == "12" ]] && [[ "$swVersMinor" -ge "2" ]] && [[ "$swVersPatch" -ge "0" ]]; then
    echo "$swVersMajor.$swVersMinor.$swVersPatch is greater than or equal to 12.2.0, removing encryption from Printer"
    sudo lpadmin -p PrinterName -E -v smb://PrintServer/PrinterName?encryption=no -m /Library/Printers/PPDs/Contents/Resources/driver.gz -o Option1=True -o "Duplex/2-Sided Printing=DuplexNoTumble" -o printer-is-shared=false -o PageSize=A4 -o auth-info-required=negotiate

    #Removes Encryption for devices with MacOS 11.6.3 or later
    elif [[ "$swVersMajor" == "11" ]] && [[ "$swVersMinor" -ge "6" ]] && [[ "$swVersPatch" -ge "3" ]]; then
    echo "$swVersMajor.$swVersMinor.$swVersPatch is greater than or equal to 11.6.3, removing encryption from Printer"
    sudo lpadmin -p PrinterName -E -v smb://PrintServer/PrinterName?encryption=no -m /Library/Printers/PPDs/Contents/Resources/driver.gz -o Option1=True -o "Duplex/2-Sided Printing=DuplexNoTumble" -o printer-is-shared=false -o PageSize=A4 -o auth-info-required=negotiate

	#Removes Encryption for devices with MacOS 10.15.7 with Security update 2022-001
    elif [[ "$swVersBuild1" == "19H" ]] && [[ "$swVersBuild2" -ge "1713" ]]; then
    echo "$swVersBuild1 $swVersBuild2 is greater than or equal to 19H1713, removing encryption from Printer"
    sudo lpadmin -p PrinterName -E -v smb://PrintServer/PrinterName?encryption=no -m /Library/Printers/PPDs/Contents/Resources/driver.gz -o Option1=True -o "Duplex/2-Sided Printing=DuplexNoTumble" -o printer-is-shared=false -o PageSize=A4 -o auth-info-required=negotiate

    #Enables encryption for everything else
    else
    echo "$swVersMajor.$swVersMinor.$swVersPatch. Leaving encryption enabled."
    sudo lpadmin -p PrinterName -E -v smb://PrintServer/PrinterName -m /Library/Printers/PPDs/Contents/Resources/driver.gz -o Option1=True -o "Duplex/2-Sided Printing=DuplexNoTumble" -o printer-is-shared=false -o PageSize=A4 -o auth-info-required=negotiate

    fi 
fi

exit sausage

 

homepup
New Contributor III

Are your systems not running the latest updates? The macOS 12.3 and later updates for Big Sur and security update for Catalina resolved the issues we were having using SMB/Windows Print servers (Papercut).

I saw on an Apple Support thread that it was 'fixed', but went and tried it myself on a fully updated device and it was still getting stuck at 'Ready to print'.

Someone chalked it down to devices relying solely on kerberos tickets for authentication. We use NoMAD and local accounts so suspect we're in the same boat.

Bob-UNCC
New Contributor

I've tried every combination offered up here with no luck. The Print Server is on 2019, the desktops are all on Monterey. Our Macs are not in AD, just using Kerberos for authentication. It fails by asking for authentication. It should not require authentication to the Print Server. That doesn't matter anyhow since entering the information still doesn't allow a print. It will sit there in the local queue with "ready to print" and paused. I've had to move people over to direct printing just so they can kill trees. 

Open to more suggestions.

Bob 

UNCC

The script I wrote and posted months ago is working in our environment for smb printing.

it basically checks version of MacOS and adds the printer via command line.

Qwheel
Contributor II

Incase people missed it: our print provider advised encryption=no basically un-obfuscates the username of the job. Which is how printing has operated for decades.

Password is still encrypted.

Bob-UNCC
New Contributor

We came up with a solution using LPD that seems to work when SMB did not. So picky with drivers!!!

 

Bob

chrisB
Contributor II

I have noticed with our printing system that this problem reappears with macOS 14.0rc (23A339) and can be solved as described.