[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