Cups 1.3.7 access denied on a Windows domain

[clodhopper]

I'm trying to setup a new CUPS server to use with Papercut but I'm about to throw my toys out my pram as I can't it to work how I need it to :-)

 

The system is a fresh install of CentOS 5.3 with cups-1.3.7-8.el5_3.4, I have added the printer (which is connected via a jetdirect card) and I can print as many test pages as I like. If a computer is logged in locally I can add the printer via ipp with something like http://192.168.0.31:631/printers/mezz and it works fine.

 

If I try to add the printer when I'm logged into the domain as a domain admin I add the port then it asks for a username & password and the only way I can get round this is by using "root" which I don't really want. I know I could add a new user to the box to use but I'm not sure if this would confuse papercut as everyone would be connecting as root.

 

What I don't understand is this used to work fine on older boxes running CUPS 1.1 so I'm guessing it's something added when we jumped from 1.1 to 1.3.

 

I can post my cupsd.conf file if this would help

 

I had thought about using Samba to share the printers but this seems over kill & I had issue's with our old cups boxes trying this hence the use of IPP.

 

Any idea's before I go to the dark side & run it all off a Windows box ??

Brian

Edited June 3, 2009 by clodhopper

[Geoff]

Open up cups.conf, check the Policy section. There's a 'Limit' section for a group of actions. Just remove the user requirement from the printing one.

[clodhopper]

This is what I have in my policy section, I even tried to setup a default policy to allow everything, without luck :-(

 

# Set the default printer/job policies...

DefaultPolicy BCH

 

# Job-related operations must be done by the owner or an administrator...

Order allow,deny

Allow from all

Allow all

 

# All administration operations require an administrator to authenticate...

AuthType Default

Order allow,deny

Allow from all

Allow all

 

# All printer operations require a printer operator to authenticate...

AuthType Default

Order allow,deny

Allow from all

Allow all

 

# Only the owner or an administrator can cancel or authenticate a job...

Order allow,deny

Allow from all

Allow all

 

Order allow,deny

Allow from @LOCAL

 

Order allow,deny

Allow from @LOCAL

[Geoff]

The sequence of the policies is important. As your last policy listed is restricted to @LOCAL only connections from localhost will be allowed.

[clodhopper]

Tried changing these lines

 

Order allow,deny

Allow from @LOCAL

 

Order allow,deny

Allow from @LOCAL

 

to Allow from ALL

 

restarted cups & still the same access denied error.

 

The bit that has me stumped is a machine not on the domain connects fine it's the ones logged into the domain that error out :-(

[PaperCut]

Hi clodhopper,

 

I'm one of the Linux developer's here at PaperCut. First, if most of your workstations are Windows, then considering Samba is a good choice. You'll find that it integrates very well with CUPS and will transparently expose the CUPS queues as standard Window shared queues with very little, if any configuration.

 

Regarding your current problem; The issue will be the slightly tighter default security settings on CentOS.

 

The default security is "Require user @SYSTEM" meaning that only local users listed in /etc/passwd can access printers. A simply solution is to open this up like:

 

AuthType None

 

and then reply on PaperCut's popup authentication to enforce security. The other options are to expose the queues via Samba (with security=domain) or setup Winbind (advanced).

 

To point out a few other CentOS traps:

 

* Access is restricted to @LOCAL by default. This means that only computers in the same Subnet as the server can access the printers. Watch out for this one if you have multiple subnets.

 

* The "Listen" setting may strict access to localhost only. Try removing this line and replacing with just "Port 631".

 

 

Hope this helps.

 

Cheers,

 

Chris

[clodhopper]

Thanks for the advice,

 

I made the changes but it still asks for a username & password. The interesting thing is that if I enter the "papercut" username that was created when I installed papercut it works fine so I'm going to give it a try with that.

 

I did experiment with using Samba & CUPS a year or so ago and it worked fine but I needed to add the printer to each user & in a college that would be a little hard, hence the use of IPP.

 

Brian

[PaperCut]

Thanks for the advice,

 

I made the changes but it still asks for a username & password. The interesting thing is that if I enter the "papercut" username that was created when I installed papercut it works fine so I'm going to give it a try with that.

 

I did experiment with using Samba & CUPS a year or so ago and it worked fine but I needed to add the printer to each user & in a college that would be a little hard, hence the use of IPP.

 

Brian

 

If you require IPP authentication, instead of using the "papercut" user I'd recommend adding a new user account on the system with a name like "student" and set the shell to /bin/false . That way you'll prevent the password from being used for a remote login (i.e. SSH).

[Ric_]

Have you checked the permissions on you SAMBA share(s) containing the printer drivers?

 

There's a wiki page at http://www.edugeek.net/wiki/index.php/CUPS_and_PyKota that might give you some ideas too - it's PyKota rather than Papercut but the SAMBA and CUPS stuff should be the same.

[clodhopper]

This one just gets more weird everyday :-)

 

I've setup two XP clients now by logging in locally so it's a printer for all users & it didn't ask for a username & password. I then logged in to the domain as a student & it all worked fine once I'd set the printer to A4 not letter in the 50 million places you have to in XP !!!!

 

Thanks for all the pointers & Gotchas so it's on with the Papercut trial without going to the darkside :-)

 

Brian