[cups-devel] SSL-encrypted CUPS IPP Basic Authentication via Active Directory
rcc2 at cornell.edu
Thu Apr 2 06:36:06 PDT 2015
Thanks for your usual quick and informative response!
Your explanation is what I suspected.
I can eliminate the ticket cache files using "ccache_dir=/dev/null" in
/etc/pam.d/cups, but this adds another 21 messages (errors) to
/var/log/messages. I can configure syslog to black-hole messages from pam_krb5,
but that seems like a Bad Idea.
I'm going to try pam_ldap to see if that's less messy.
In general, do you think this is a viable strategy for authenticating print job
submission for a campus the size of Cornell?
On 4/1/15, 7:46 PM, Michael Sweet wrote:
> Since IPP (and HTTP) has no notion of a login or session, every IPP request issued by the client (Get-Printer-Attributes, Get-Job-Attributes, Create-Job, Send-Document) gets authenticated, so you'll see a PAM call for each request that is processed by cupsd.
>> On Apr 1, 2015, at 5:33 PM, Rick Cochran <rcc2 at cornell.edu> wrote:
>> I have a campus full of OS X and Linux users whose print job submissions I would like to authenticate via Active Directory. The good new is that I already have this working. I would just like to make sure I'm doing it optimally.
>> What I have working is CUPS using pam_krb5 to authenticate to AD. The strange thing I am seeing is that each print job authentication results in 21 Kerberos ticket cache files created in /tmp, and 21 "authentication succeeds for 'rcc2'" messages and 21 "TGT verified" messages logged to /var/log/messages.
>> It seems as though CUPS is making 21 authentication calls to PAM. This seems rather excessive. Perhaps there is a way to reduce it.
>> Another possibility would be to use pam_ldap instead of pam_krb5. Is there some reason to believe that would be a better solution?
>> Thanks for any help.
>> cups-devel mailing list
>> cups-devel at cups.org
> Michael Sweet, Senior Printing System Engineer, PWG Chair
> cups-devel mailing list
> cups-devel at cups.org
More information about the cups