Bug 842782

Summary: CUPS cannot print with smbspool backend in AD / Kerberos environment
Product: [Fedora] Fedora Reporter: Sandro Mathys <sandro>
Component: cupsAssignee: Tim Waugh <twaugh>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 17CC: abokovoy, asn, gdeschner, jlayton, jpopelka, sbose, ssorce, twaugh
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-08-03 11:17:05 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Sandro Mathys 2012-07-24 15:24:58 UTC
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 06:47:36 UTC
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 10:41:21 UTC
Sandro: are the client and server running on separate machines, or both on the same machine?

Comment 4 Sandro Mathys 2012-08-03 10:51:07 UTC
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 11:17:05 UTC
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 ***