Skip to main content

We started using Uniflow this year or SMB print queues. Before I had done direct IP printing. I am running into a weird issue where sometimes when a user prints it deletes the Kerberos ticket. It then either recreates it or just removes it. If it removes it the user is unable print after the job finishes and the print jobs after fail at hold the job for authentication. Even if it recreates the Kerberos ticket when it prints the next time it might not leaving a random failure to print. I had been chalking the issue up to not rebooting for awhile but the last user had reboot a few hours before. If I reboot the machine it will most likely start printing again without issues.

Devices are running 10.9.5 mainly. I have a few running 10.10.5 and 10.11.5. They are all bound to the domain and working correct for authentication.

Printer is installed using a script
lpadmin -p "Name of Printer" -E -v smb:PATH TO SERVER -P "Path to Driver" -D "Name of Printer" -o auth-info-required=negotiate -o sides=two-sided-long-edge -o media=letter I have tried adding -o printer-op-policy=authenticated but haven't seen much change. Maybe after a reboot

I am using ADPASSMON and Kerbminder to help keep the AD connection running smoothly. I have tested both and they appear to be working correctly.

To see what was happening I Launched Ticket viewer from ADPASSMON
I would see a valid, expired or nothing for the ticket
If ticket wasn't valid I would run /Library/Application Support/crankd/KerbMinder.py from Kerbminder to force an update to the Kerberous ticket
Sometimes this got them back to printing
Sometimes this got them printing once page and it deleted the ticket
Sometimes it did nothing. I would see the ticket be generated but if I tried to refresh the ticket via ADAPSSMON it would say no valid ticket. Close ticket viewer and reopen and ticket would be gone. And print jobs would be stuck at hold for authentication.

Anyone have any ideas why Kerberos tickets would act this way? For some users it seems to be fine without issue. Others randomly stop working and might have to reboot two or three times in a day to be able to print.

Hi,

I have a very similar set up to you, UniFlow, and ADPassmon, but we are entirely 10.11.6. The only issues we currently have are when a staff member has not authenticated in days (generally after a weekend!).

I do, however, remember that 10.9 was more "touchy" on Kerberos, than 10.11 has been. I'm not sure if it was a kerberos policy from AD that was causing it, or just the way 10.9 handled Kerberos.

The other issue from 2-3 years ago was DNS. I started putting the full DNS name into the server path, and the issues all disappeared!

Hope this helps.

Tim

Uniflow ... shudder.

Anyway, try setting up an LPD print queue instead of an SMB one. I've found that to be a lot more reliable in operation.

Ill give that a try thanks

I'm testing uniFLOW at the moment too and it's not playing nice with SMB/Kerberos here (AD environment) - same issues with prompting for credentials all the time. I'm having great results with LPD.

To follow on, I do all Mac printing via LPD whenever I can. It's so much more reliable in operation than SMB.

Same here with previous print systems - we've always used LPD wherever possible.

Changed to LPD and it now ask for my password everytime

lpadmin -p "D123-Secureprint-ldp" -E -v ldp://olhd-printer/Follow_Me -P "/Applications/UniFLOW/MomUd-custom-Duplex-11x17.ppd" -D "D123-SecurePrint-ldp" -o auth-info-required=negotiate -o sides=two-sided-long-edge -o media=letter -o printer-op-policy=authenticated

From my research the above command should be right.

Also have any of you noticed a difference between using DNS name vs IP? Right now this just has the first part of the FQDN should it have it all? Or would IP be better so it doesn't have to resolve?

Thanks

@nmanager Should use FQDN.. also, sure the print server is kerberised?

Yep, FQDN in use here and Kerberos. No issues at all. I'm also testing against the Canon UFR II drivers as our printers are Canon MFDs. I'm only responsible for the Mac side of this (someone else manages the print servers) but it's looking good and jobs are showing proper charges associated with them.

As part of my testing, I deployed the printer the 'Casper way' and got it into the JSS in a couple of ways - by defining it in the JSS and uploading the correct Canon PPD, or adding it in System Preferences manually, tweaking settings (enabling stapling) and using Casper Admin to import. Both scenarios worked.

Assuming you have Canon too because of uniFLOW.

@ bentoms Print server is joined to the domain and I am able to log into it with AD credentials.

@neil.martin83 Canon here as well. Switched to FQDN. I will have to try deploying via Casper to see if that changes things. Right now I can only get SMB working without ask for authentication. Ill try capturing the printer and see if that changes things.

Ok so I created the printer via the GUI and then deploy via Casper after capturing. Doing it that way allowed me to be able to print without getting the prompt for authentication. I will see how LPD with FQDN works.

Thanks for all the help

+1 for LPD queues; I saw all sorts of 'Hold for Authentication' type issues with SMB.

We needed to deploy SMB queues to those Macs whose local account names didn't match what was in AD. Now that we are enrolling Macs into Casper (and binding them to AD), we can use LPD queues and printing goes a whole lot smoother....

Terms & ConditionsCookie settingsAccessibility statement