Are your clients logging in with directory accounts? If so, that's an NTLM authentication prompt. Likely the user does not have a valid Kerberos ticket.

Run this on a client in Terminal:

klist -a

If there are no tickets listed, then we'll troubleshoot why the client isn't pulling a TGT at login. If the ticket is listed, but expired, we'll need to look into user behavior (i.e. the user never logs out and the ticket expires after a day).

Hello Uniflow, my old fiend ...

Stupid stuff first. If you've AD users, why aren't you printing via lpd? I found that to be more reliable in passing over AD credentials to the print server. My former place had it set up for samba printing (smb) for windows and lpd for OS X as a postscript queue.

Liase with Canon on that. The Uniflow backend is a nightmare.

The other thing to try after that is twiddling with CUPS authentication settings. Consult the docs but setting cups to use "basic" may also help.

Lastly, I never used the print queue software helpers they provided mostly because it was out of date. Ditch that too as a test.

@franton
I live in an environment of extreme delegated access -- we're a pretty big shop, so we have a different team for basically all levels of administration for infra, networking, and OS X/Windows. I am on the OS/App packaging team so I basically have to figure out how to package what the rest of the teams and the business already had set up/agreed on.

@bmwarren
Both machines I ran the kerberos tool on returned tickets. My personal Mac gave me the cache, principal, and cache version. My test VM returned this plus a few other lines including "auth time, end time, and renew till" fields. What thoughts do you have here sir?

@rseys You're not in my former workplace are you? A certain university ... I'm quite aware of the pressures of such an environment: you have to convince them to work with you rather than impose decisions on you. If they don't, it's time to get out as your job stress will be intolerable after a while .. and you'll get the blame when it goes wrong too.

You're down at this point to manually setting up your printer queue, capturing the /etc/cups/printers.conf file. Then deploying your queue from Casper and comparing your known good config with what's being pushed. That'll tell you if there's any capture/deployment issues from within Casper itself.

For what it's worth, I had the same issue on a different matter on 10.6 computers with Filewave. Print object for one queue would work and fail utterly for another queue. Ended up scripting the print queue creation ... may be worth considering that approach.

@resys
Put it to the /Library/LaunchDaemons instead of LaunchAgents.
Also change the file permissions/modes like this;

$ sudo chown -R root:wheel /Library/LaunchDaemons/com.318.cupswatcher.plist
$ sudo chmod 644 /Library/LaunchDaemons/com.318.cupswatcher.plist

$ sudo chown -R root:wheel /usr/local/bin/configureCUPSKerb.sh
$ sudo chmod a+x /usr/local/bin/configureCUPSKerb.sh

@Kumarasinghe -- did everything you listed...same error what I try to launch the "daemon" :(

@franton -- I have everything working correctly as far as mapping the printers, installing drivers, etc...I feel like I'm so close! It is just a pesky password prompt for AD credentials upon printing. I would really hate to start from scratch and script :-

Hey everyone, any other ideas as to things I could try? Again, I am just trying to suppress the "hold for authentication" message when a user tries to print via uniFlow where they need to type in AD credentials.

I am looking at adding via lpadmin something like this:

lpadmin -p SecurePrint1 -E -v smb://myserver/myprinter -m mom.ppd

...the issue I am having is this: my sysadmins provided me with the above .ppd on a flash drive....how do I go from flash drive only to being able to deploy it to hundreds of users...could this be as simple a capture with Composer? Or could I copy it from a network share to our machines? Lastly, if I am manually copying the .ppd would the destination location have any significance?

Thanks everyone

Try this, ```

!/bin/sh

cupsctl DefaultAuthType=Negotiate
```
This is what I use in our environment with printers deployed on Win servers.

@msblake -- I'll give this a shot!

I do have a question about the -m mom.ppd (the settings/driver file) -- in order for me to script this, where must "mom.ppd" live? Is there a specific directory?

@rseys It's the full path to that file, so it can go wherever you want it to go. Most printer driver installations put them in /Library/Printers/PPDs/Contents/Resources/

Have you thought about using the uniFLOW Mac client? We couldn't add uniFLOW the normal way because it didn't give the user much options and the price didn't reflect properly.

I can confirm that the solution provided by Araneta works. I just tested it with 5 different AD based printers in my office and was not once prompted to authenticate like I always have been.

@msblake your solution worked great!

For anyone in a similar boat to me (adding printers from Casper admin not working as expected), here is what I ended up doing: 1. Using composer: Monitor File System Changes > drop PPD file into /Library/Printers/PPDs/Contents/Resources
2. Save as dmg and upload to JSS with Casper Admin
3. Created a new script in JSS:

lpadmin -p DesiredPrinterName -E -v smb://myserver/myprinter -m /Library/Printers/PPDs/Contents/Resources/mom.ppd -o auth-info-required=negotiate

4. Created a new Policy, added the dmg from step2, added the script from step3 to this policy.

No more prompts for AD credentials when printing :) Thanks everyone for the help!

If you are using Compser to accomplish this task, the steps are easier than described:
1. Put your PPD into /Library/Printers/PPDs/Contents/Resources
2. Open Composer and hit Cancel on creating a new package
3. Drag the PPD into the left pane
4. Expand the package within the left pane
5. Right click Scripts and select Shell Script > postinstall
6. Add your install script into the contents of that file. In this case lpadmin -p DesiredPrinterName -E -v smb://myserver/myprinter -m /Library/Printers/PPDs/Contents/Resources/mom.ppd -o auth-info-required=negotiate

You now have a full printer installation package. No need to have a script in the JSS for this, it's built in.

@ryan.s @mscottblake

Is there any way to make the default printing color black & white? Right now, if we print using the method above, the default is color. We charge departments based on which color they print.

.2 cent for B&W

.10 cent for Color.

The issue is by default, when Secureprint is added manually or by the command above, it will print in color and only charge the department .2 cent.

What we did (same as above):

lpadmin -p Secureprint -E -v smb://printserver/Secureprint -m /Library/Printers/PPDs/Contents/Resources/MomUd.ppd -o auth-info-required=negotiate

You may find something useful in my github examples

We have mono setup as a default.
Also no authentication prompts from either AD or non AD bound machines.

Dumb question but there is not .ppd files in /Library/Printers/PPDs/Contents/Resources so why put it there?

@marklamont

Whenever I go to print, it's always in color. It just ignores the mono setting.