[cups.development] Kerberos multiple personalities

Andy Polyakov appro at fy.chalmers.se
Thu Nov 6 08:43:03 PST 2008


>>> Alternative approach could be to examine 
>>> User-Agent field in HTTP header and assume different personalities 
>>> depending on outcome, specifically if User-Agent is CUPS/*, then assume 
>>> ipp at server identity, otherwise HTTP at server.
>> Or better yet, see if request's Content-Type is application/ipp. As far 
>> as alternative approach goes that is.
> 
> That won't work for getting the PPD file of a Kerberized queue.

Note that this "alternative approach" is not my preferred choice anyway, 
so that I'd prefer if we concentrate on the original suggestion:-)

> We haven't seen any other reports of problems using Kerberos
> authentication with the web interface, and I've personally setup and
> used CUPS with Kerberos authentication enabled with Safari and
> Firefox.

??? As per RFC4559 Firefox (as well as IE, I don't know about Safari) 
asks for tickets to HTTP/server at KDC, or in GSS terms they pass 
HTTP at server to gss_import_name. If I just follow the suggested procedure 
and set up ipp/server principal, then web browser can't even pull a 
ticket, because there is simply no HTTP/server principal. As result 
browser gets 401 Unauthorized, and nothing is logged in error_log, 
because this reply is natural part of GSS negotiation.

Next I create HTTP/server principal [and naturally merge corresponding 
keys to cupsd's keytab]. Attempt to connect results in end-less loop in 
Firefox, i.e. it attempts to connect and reconnects, and reconnects, 
etc. Nothing is logged in error_log unless I increase LogLevel to debug. 
In which case I can see following debug messages:

cupsdAcceptClient: 11 from xx.xx.xx.xx:631 (IPv4)
cupsdReadClient: 11 GET /admin HTTP/1.1
get_gss_creds: Attempting to acquire credentials for ipp at server...
get_gss_creds: Credentials acquired successfully for ipp at server.
cupsdAuthorize: Error accepting GSSAPI security context: Unspecified GSS 
failure.  Minor code may provide more information, Unknown code krb5 144
cupsdIsAuthorized: username=""
cupsdSendError: 11 code=401 (Unauthorized)
cupsdSendHeader: WWW-Authenticate: Negotiate
cupsdCloseClient: 11

So what do we do? Add GSSServiceName HTTP to /etc/cups/cupsd.conf... Now 
Firefox works and I see following debug messages:

....
get_gss_creds: Attempting to acquire credentials for HTTP at server...
get_gss_creds: Credentials acquired successfully for HTTP at server.
cupsdAuthorize: No delegated credentials!
cupsdAuthorize: Authorized as user at REA.LM using Negotiate
....

[As for "no delegated credentials." I'll be discussing this at some 
later point in separate context.]

But what about lpr? Now lpr fails printing "Unauthorized", while cupsd 
logs messages identical to above mentioned, i.e. failing to accept 
GSSAPI security context. Naturally I can set environment variable 
CUPS_GSSSERVICENAME to HTTP and have lpr working, but as already 
mentioned we don't consider it practical (in other words, don't want to 
cope with users who fail or forget to set it up).

KDC is Heimdal, while cupsd and clients are linked with [various 
versions of] MIT libraries. A.





More information about the cups mailing list