Bug 842782 - CUPS cannot print with smbspool backend in AD / Kerberos environment
CUPS cannot print with smbspool backend in AD / Kerberos environment
Status: CLOSED DUPLICATE of bug 837602
Product: Fedora
Classification: Fedora
Component: cups (Show other bugs)
17
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Tim Waugh
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-07-24 11:24 EDT by Sandro Mathys
Modified: 2012-08-03 07:17 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-08-03 07:17:05 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Sandro Mathys 2012-07-24 11:24:58 EDT
I think I'm seeing the same as in rhbz#565774 in F17. That rhbz was for RHEL 5 and has been fixed long time ago but I can't find a similar reference in the samba changelog in Fedora.

Users on our systems get a Kerberos ticket when logging in and they use it to mount their CIFS homes (i.e. it's working and valid). But printing to a Windows Printer fails.

With smb://server/printer I get:
E [24/Jul/2012:17:22:20 +0200] [Job 21] Session setup failed: NT_STATUS_UNSUCCESSFUL
E [24/Jul/2012:17:22:20 +0200] [Job 21] Session setup failed: NT_STATUS_LOGON_FAILURE
E [24/Jul/2012:17:22:20 +0200] [Job 21] Tree connect failed (NT_STATUS_ACCESS_DENIED)


With smb://server/printer?k I get:
E [24/Jul/2012:17:22:54 +0200] Authorized using Basic, expected Negotiate!
E [24/Jul/2012:17:22:54 +0200] Authorized using Basic, expected Negotiate!
E [24/Jul/2012:17:22:54 +0200] Authorized using Basic, expected Negotiate!
E [24/Jul/2012:17:22:54 +0200] Authorized using Basic, expected Negotiate!
E [24/Jul/2012:17:22:54 +0200] Authorized using Basic, expected Negotiate!
E [24/Jul/2012:17:22:54 +0200] Authorized using Basic, expected Negotiate!
E [24/Jul/2012:17:23:08 +0200] [Job 22] Session setup failed: NT_STATUS_UNSUCCESSFUL
E [24/Jul/2012:17:23:08 +0200] [Job 22] Session setup failed: NT_STATUS_LOGON_FAILURE
E [24/Jul/2012:17:23:08 +0200] [Job 22] Tree connect failed (NT_STATUS_BAD_NETWORK_NAME)
E [24/Jul/2012:17:23:08 +0200] [Job 22] Unable to connect to CIFS host, will retry in 60 seconds...

Both are when trying to print a test page from system-config-printer which is running as the user.
Comment 1 Sandro Mathys 2012-08-03 02:47:36 EDT
Re-assigning to cups as calling smbspool seems to handle kerberos tickets just fine, if started as the correct user. But cups starts all its backends either as lp or as root instead of $user and therefore the backend doesn't have access to the ticket.
Comment 3 Tim Waugh 2012-08-03 06:41:21 EDT
Sandro: are the client and server running on separate machines, or both on the same machine?
Comment 4 Sandro Mathys 2012-08-03 06:51:07 EDT
Tim, not sure what clients and servers you mean and I'm not exactly familiar with the terminology of AD/Kerberos/Printing, either. If you mean CUPS: it's all on one system, locally. Everything else (print server, active directory, KDC) are distributed systems in the local network.

Oh, I forgot to mention that at some point I configured CUPS (cupsd.conf) to use Kerberos authentication but then figured that's only used within CUPS...for the WebUI and probably(?) for the client/server relation you're wondering about. It's possible that at least parts of the above log output is based on that, not sure.

What I'm 100% sure of is that the smb backend is usually started as lp and others are either run as lp or possibly root.
Comment 5 Tim Waugh 2012-08-03 07:17:05 EDT
Sorry, I meant the CUPS client and server. There is an issue at the moment with Kerberos authentication in CUPS when the CUPS client is on the same machine as the CUPS server, and this seems like it might be a symptom of that.

I believe you do need to configure CUPS to use Kerberos authentication as that's the only way the backend can get hold of the ticket.

*** This bug has been marked as a duplicate of bug 837602 ***

Note You need to log in before you can comment on or make changes to this bug.