Skip to main content

Hi everyone,

I'm in a perpetual keychain nightmare. I'm using local accounts with the kerberos configuration to manage passwords, and everything is running smoothly so far, EXCEPT printing. I continuously have keychain errors with users, and sometimes the keychain entry doesn't even exist for the printer. For example, today a professor came by after changing her password, received the "hold for authentication" error, came to the Help Desk, and there is no keychain entry for the printer in question. In the past, I've found that simply erasing everything that exists under "login" fixes this most of the time, but it doesn't make any sense, and I'm constantly having to help customers out with this issue. 

My question, how are you handling printing with a windows print server? Specifically if you're using local accounts? Would NoMad be a solution here? 

Thanks,

Mike

It took us awhile, but we are finally moving to direct IP print queues for our mac's. We have two windows print servers and over the last couple years printing has gotten more and more problematic on the mac's due to various kerberos issues. We implemented NoMad this year specifically with the hopes of an improvement to the reliability of kerberos on the macs but it literally seems to have done nothing to resolve the on hold for authentication message we receive most of the time. So far with direct IP Print queues we haven't had a single instance of the "on hold for authentication" nor the "error while printing". Obviously not everyone can use an IP based print queue, and we are losing the ability to track print jobs via papercut now, however, the elimination of the error messages we truly couldn't solve outweighs any negatives.

 

Hi @MikaelDez,
we have  different locations and at each location a separate print-server.
I made a few policies (and scripts) to provide the printer to the clients.
First of all, we are installing the printer drivers to the clients. The we are mapping the printer of our headquarter with a policy. If the employee changes the location, the client will get automatically the spooler oft his current location.
This works, because we have different ip-masks at our locations. The trigger is the change of the networkstatus.
The user authentication is the domain username and his domain password. This works on all of our locations.
The change in the background is only to change the print-sever. The spooler name is the same on each location.

The user has to autheticate only one time (at the first print job), then the authentication is stored in the keychain.
To change the users password in our windows domain, we are using NOMad. We install NOMad on each client (and made some individual changes at the menu). 

On our iPads we have AirPrint enabled which works flawlessly.

This was achieved by installing PaperCut on the Windows print server and utilising a single print queue (follow me) for our fleet of 30+ copiers.

When users print it will ask for their Windows AD credentials and then they can release the job from any copier. 

With this solution we haven't seen any Keychain issues, but I suspect your issue is related to the MacOS side of things?

Reply


Terms & ConditionsCookie settings