Mac printing issue after Microsoft Windows print server update - KB5005623

[rcorbin]

After installing KB5005623 on our Windows print server it seems to have broke printing from macOS to our SMB queues. Windows machines seemed unaffected as were macOS clients printing via LPR. We have heard that uninstalling it will restore printing from Macs. But we do have print servers at 50 sites and each would require an uninstall and reboot. If the Windows machines are still printing I'm wondering if there is something that can be done on the Mac side that will allow them to print as well. 

[JeffBugbee]

Checkout this fix https://community.jamf.com/t5/jamf-pro/smb-printing-to-windows-print-server-failing-to-connect-to-se...

Adding the printer with encryption=no is working my Macs for now

[Ehouston3]

We are experiencing the same issue. I found in testing that if you enter your credentials in the format of domain\account jobs will go through. This only works in the betas, I can confirm this with the most recent beta of 12.3. It doesn’t seem to work with a Kerberos ticket.

I’ve enabled debug logging in cups but, haven’t been able to find anything useful. I can see jobs go through but, not how the username entered gets translated. At one point I did see an escaped version of the credential: DOMAIN\\\\account in the logs.

We are still deploying the URI modification in the interim.

[Ehouston3]

In 12.3 if you destroy your kerberos ticket, and send your credentials across using domain\username, it will work. We're still struggling in our environment as well. Prior to that folks could enter just their username and the translation would happen.

[abnaau]

We still seem to have "RpcAuthnLevelPrivacyEnabled = 0" required on our windows print servers. 
Anyone have SMB kerberos printing working without it?

[Ehouston3]

We still have it set in our environment. We're also deploying a krb5.conf file as well, I recall this was to address a Kerberos issue we had with JC at the time. Not sure if it's still needed, we've not stopped the deployment since setting it up in 2022, and it's not hurting anything. It was needed then. To answer your question no, we still have it set to "0".