[cups.general] Kerberos authentication - help needed - take 2

Rick Cochran rcc2 at cornell.edu
Tue Aug 12 11:58:38 PDT 2008


Michael R Sweet wrote:
> Rick Cochran wrote:
>> No one has responded to my original request.  It would help even only to know why.
> 
> I'm pretty sure *I* did.

I received no response, and there is none in the list archive.

>> ...
>> Is Kerberos authentication in CUPS something which is there, but not well 
>> supported or used?
> 
> Kerberos authentication is there and works.  However, a *lot* of sites
> don't actually use Kerberos correctly which can cause problems for
> client printing - the key is that the clients must have a stable
> hostname and be setup with service granting tickets (SGT) so they can
> forward the user credentials from the client to the server.

I have a service principal, if that's what you mean.

> Also, you need to use either Heimdal Kerberos or a new enough version
> of MIT Kerberos (1.6.3 or higher) to get credential caching/forwarding
> to work.

I have krb5-libs-1.6.1-17.el5_1.1 on my client workstation, and 
krb5-libs-1.3.4-54.el4_6.1 on my server.

>> Finally, I would like to mention that there appears to be a lack of adequate 
>> debugging output for CUPS authentication functionality.  I can't find any useful 
>> information as to what happened during the authentication process.  The message 
>> "Print-Job: Forbidden" tells me nothing.
> 
> Use "cupsctl --debug-logging" or check the "log debug info" box in
> the web interface - that will provide additional information about
> the authentication process.
> 

page4> sudo /usr/local/netprint/cups/sbin/cupsctl --debug-logging
cupsctl: Unauthorized

So I kinited myself and tried it thusly:

page4> /usr/local/netprint/cups/sbin/cupsctl --debug-logging
cupsctl: Unauthorized

At which point I get the following in the error_log with LogLevel debug2:

D [12/Aug/2008:09:24:10 -0400] cupsdAuthorize: Authorized as 
rcc2 at CIT.CORNELL.EDU using Negotiate
d [12/Aug/2008:09:24:10 -0400] cupsdIsAuthorized: 
con->uri="/admin/conf/cupsd.conf", con->best=0x93c5e08(/admin/conf)
d [12/Aug/2008:09:24:10 -0400] cupsdIsAuthorized: level=CUPSD_AUTH_USER, 
type=Negotiate, satisfy=CUPSD_AUTH_SATISFY_ALL, num_names=1
d [12/Aug/2008:09:24:10 -0400] cupsdIsAuthorized: auth=CUPSD_AUTH_ALLOW...
D [12/Aug/2008:09:24:10 -0400] cupsdIsAuthorized: username="rcc2 at CIT.CORNELL.EDU"
d [12/Aug/2008:09:24:10 -0400] cupsdIsAuthorized: Checking user membership...
d [12/Aug/2008:09:24:10 -0400] cupsdReadClient: Unauthorized request for 
/admin/conf/cupsd.conf...
D [12/Aug/2008:09:24:10 -0400] cupsdSendError: 7 code=401 (Unauthorized)

This is semi-encouraging since it's the first time I have seen any evidence that 
any Kerberos authentication is taking place.

Aha!  After adjusting the authorization requirements in cupsd.conf manually, 
this last command above now works.  And I appear to be getting some useful 
debugging information.

But now all the comments in my cupsd.conf have been removed, and I will have to 
restore them from backup.  Sigh.

Additionally, Kerberos works with the cupsctl command _only_ when it is executed 
on the server.  It does not work when the cupsctl command is executed from the 
client.  Is this because the server is using too old a version of MIT Kerberos? 
  If so, then that could explain everything.

Thanks for your help.
-Rick





More information about the cups mailing list