PaperCut + OS X + SSO = bliss

I do exactly this thing for Uniflow printers too. Do you run the following command? I find this helps a lot as well.

cupsctl DefaultAuthType=Negotiate

Hi Richard,

Good question, I'm not sure if that command was run on the test users' Macs. For initial testing we took a freshly imaged Mac (as per JAMF's Baseimage guidelines) and we didn't need to run that comand. I think we didn't have to because we set the Operation Policy to authenticated (instead of kerberos)? In our case looks like we may not need to but I'm compelled to ask, in what ways is that commend helping you? Worth asking, in case we're overlooking something on our end. :)

It's an odd one. I found the following things:-

1) If I didn't run that command AND change the operation policy on the printer objects, AD pass through authentication wouldn't work. Leaving either of these things out bugged the user for their username and password every time.

2) If I created the printer object via command line, AD pass through wouldn't work period.

3) If I created the printer object via the GUI then set the operation policy and pass that command, everything works as it should.

I then implemented that command as part of our change control policies. That's the only way I got it to work albeit on a different system on 10.8. I came to the conclusion that there's some information being created and stored somewhere that I couldn't replicate without doing all i've mentioned. I've not had any time to investigate further.

The only difference between Papercut and Uniflow is that Uniflow requires lpd instead of smb despite being on a windows print server.

Guys not sure if this thread would be of any help to you. https://jamfnation.jamfsoftware.com/discussion.html?id=4075

We've got things working as designed now. The missing piece of the puzzle was the user authentication prompt.

Exactly. As long as it works ;)

@Don

We are on OS X 10.8.2 and we identified an issue with Kerberos single sign-on WITH PaperCut (11.4)
Users get re-authentication prompts after an initial successful print to their SMB print queues. Specially when you use TextEdit.

Kerberos ticket will get created at login but ticket will get destroyed once after an initial successful print and prompts for re-authentication at then next print.

"klist" shows a valid ticket after login but will be empty after I print for the very first time.

Can you please follow these steps and let me know if you can produce this issue;
1. Open TextEdit and print to a PaperCut queue
2. While TexetEdit is opened edit the same file and print again
3. If the Step 2 didn't prompt you to re-authenticate, please print the same document couple of times and see if it prompts you to re-authenticate.

Also if you do a Test Print from the printer settings it prompts to re-authenticate.

Please let me know.

Also...

run -o printer-op-policy='authenticated' twice on the same printer and see if it prompts for password afterwards.

Thanks

Take a close look at the image I posted; we are leveraging cached AD credentials. ;) It sounds like you're running an old version of PaperCut and relying on Kerberos. You might want to contact your vendor/integrator for guidance on getting your scenario to work.

@Don
Can you please tell me more about your PaperCut setup and any additional changes you made to get cached AD credentials for authentication?

I have spoke to our PaperCut integrator and he said he couldn't find any information about your setup/diagnostics from PaperCut engineers.

Thanks

I have to ask how this is different from what we are doing?

We have all of our Mac's bound to AD and the users use their AD username/password to login to the Mac. The printer queues are all on Win servers.

If we install the printers with the SMB method on the Macs, Papercut sees the user print jobs correctly and assigns them to the AD user account. No client. No special CUPS commands.

Just wondering

@lehmanp00 All environments are different, and solutions like this are tailored for the environnent (usually not turn-key). If it works without issues, your integrator probably got it right the first time around. :) Our integrator didn't have the answer, and neither did we - but working together we figured it out (with help from our ace Wintel team).

@Kumarasinghe As I stated previously, you're running an old version of PaperCut and relying on Kerberos...YMMV, you'll need to work this out with your integrator. They are the architects, and they're getting paid for the solution, make them earn their pay by keeping the pressure on until they get the issue(s) resolved.

Don,

How do you package/distribute your printers via Casper? I created a dmg with Composer, but it doesn't keep the auth policy.

-tep

I see so many references to people using lpadmin with the JSS to add/remove printers. We attempted to deploy Papercut last spring at our school and have been halted for over half a year while trying to devise a plan to add/remove queues with the JSS that uses Kerberos authentication. The easiest way seems to be using lpadmin to add the queues with the Operation Policy Authenticated (-o printer-op-policy=Authenticated) and tell the CUPS server to authenticate to our Windows print queues with Kerberos using "cupsctl DefaultAuthType=Negotiate". I can make it work when entering the commands through Terminal as root on each machine individually, but for the life of me, I can't get the commands to run without needing to pass the root password with the JSS. It's not consistent, but I almost always get "Unauthorized" when running cupsctl or lpadmin through the JSS. Can anyone please explain how you're running lpadmin commands through the JSS?

Woah, sorry, I missed the last two posts on this thread.

@tep We push the drivers usually a silently-deployable PKG/MPKG from vendor, else we make it so. Then we use Casper to add the printer, which works for simple printer setups. For more complex printer setups (PaperCut, Fiery, Creo, etc.), we use lpoptions/lpadmin using scripts.

@McNeil We create scripts, upload to JSS and push them to the target computers. @stevewood has some excellent posts regarding how to use lpoptions/lpadmin (which would be nice to get into the JAMF Nation knowledge base).

I just wanted to circle back to this topic and post some findings I've had with 10.9 and 10.10 clients. It appears that the correct way to get the authentication prompt to go away for AD bound machines is simply adding the option

-o auth-info-required=negotiate

to your lpadmin command.

For example (and to quote @rhysforrester at https://jamfnation.jamfsoftware.com/discussion.html?id=4075#responseChild19303)

For printers you've already installed on the system run the following command;

lpadmin -p PRINTERNAME -o auth-info-required=negotiate

To setup a new printer you would use:

lpadmin -p PRINTERNAME -E -v smb://PRINTSERVER/PRINTQUEUE -m Generic.ppd -L "LOCATION" -o auth-info-required=negotiate

I have added this one option to the lpadmin command and had great success. It appears that the

-o printer-op-policy=Authenticated

and

cupsctl DefaultAuthType=Negotiate

are not needed.

I was having this problem with only specific users. Some were having the issue on specific printers other were having the issue on all system printers.

For those with specific printer problems I used:

lpadmin -p PRINTERNAME -o auth-info-required=negotiate

For those with the problem on all the printers I used:

lpadmin -p all -o auth-info-required=negotiate

@n8felton Thanks for the advice my man. I just implemented this in a day because of your help.

Have you noticed a delay of about 10 seconds when user hits print? That's the only issue I seem to be having right now.

Also, for future reading of this thread... do not user the built in method of capturing and deploying printers. Use a script. LPADMIN all the way with this one, it will save you trouble.