LDP uses a different port than SMB, check your firewalls are not blocking the LPD port.Ĥ. The print queue is setup to use kerberos.Ĭheck in 3.
User the "/usr/bin/klist" command or look in the "Ticket Viewer.app"Ģ. The user has a kerberos ticket when trying to print. I'd start by double checking the Macs which are having trouble printing and check the following:ġ. I'm no expert with SSO but if you have a kerberos ticket then printing to a windows print queue via any URI supported by the server should work so long as the print queue on the Mac is configured to use kerberos. I really hope something is released by either Microsoft or Apple, as this issue that started out as a minor nuisance is swiftly becoming a big problem. I might need to solve this by circumventing the print server all together, but I don't want to do that as I won't be able to cancel jobs that get stuck in the printer. The printers are deployed via Jamf Pro, and are mapped via smb://servername.ad./Printer_Name/ Once trying to authenticate a job sent via NoMad, job gets sent and just says, "Connecting to printer" and nothing happens. On my site we use Server 2019, and use NoMad to connect to it. Going to keep troubleshooting, but this is an issue that is frustrating and causing real problems, as staff members are starting to get antsy. I have almost 100 users unable to print, and I tried the fix suggested by craigo, but unfortunately hasn't bore fruit. Currently running Windows Server 2019, and everything was working until middle of last week ().
You could disable the setting while you implement the LPD service on the print server and change all your macOS client printer setups, then re-enable it again once you've fixed your macOS clients, or hopefully Apple will release a patch to increase the security settings used by macOS to print to windows print queues.Ĭan also attest to having this problem.
NOTE: You will need to restart your print spooler service, in complex print environments you will need to restart all print related services or restart the server. In the Value data box, type 0 and then click Ok. Right-click RpcAuthnLevelPrivacyEnabled and then click Modify. Type RpcAuthnLevelPrivacyEnabled and then press Enter. Right-click Print, choose New, and then click DWORD VALUE (32-bit) Value. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print Right-click Start, click Run, type cmd in the Run box, and then press Ctrl+ Shift+ Enter.Īt the Administrator command prompt, type regedit and then press Enter. To d isable the increased authentication level requirement on your print server, follow these steps:
NOTE: this still leaves your server vulnerable to the issues the security update address, but it allows you to easily switch it back and forth should you need to. OR you can reduce the authentication level requirements on your print server. I haven't tried this yet but rather than uninstalling the update you can d isable the increased authentication level requirement on your print server via registry key settings.
*Prerequisites: install LPD service in the print server:" This may be a solution for consideration. Setup local lab to use Windows with LPR.exe to simulate the MacOS client. If this is the case, the MacOS needs to fix the RPC auth level issue.įrom our side, we made a test in our lab:
MacOS does not use the higher level of authentication methods required by Windows Printer Server since 9B.īased on the ETL, It seems Mac OS client using SMB/RPC printing from MacOS to Windows. " Cause: This confirmed printing is failing due to an auth failure, as the printer sever installed with 9B determines the level of RPC authentication required on the client side. We opened a case with Microsoft, submitted requested logs and they confirmed this was a macOS client issue.