Printer status error - "Access Denied"

  • Thread starter Thread starter leffe911
  • Start date Start date
L

leffe911

Hi All,

Need some confirmation on what is required to allow network printing,
print server running Win2003 and client is WinXP SP2.

The queue is setup on Win2003 STd server which is member of AD domain
(Win2003 native).

The domain policy being applied forces these settings:

Network Access: Do not allow anonymous enumeration of SAM accounts -
Enabled
Network Access: Do not allow anonymous enumeration of SAM accounts and
shares - Enabled
Network Access: Named Pipes that can be accessed anonymously - Enabled,
set to null value

------------------------------------------------------------------

When I connect a printer from an XP workstation the printer connects
successfully. I am able to print a job sucessfully
however the "Status" of the printer in the Printer and Faxes window
displays - "Access Denied, Unable to connect"

I believe this issue may be caused because the spooler service on the
print server is unable to communicate successfully with
the spooler service on the workstation.

I have created a test OU and moved the workstation to this. I have then
applied a test GPO, in this GPO I set
Network Access: Named Pipes that can be accessed anonymously - Enabled
= SPOOLSS.

Effectively this allow anonymous access to the Spoolss named pipe, and
when I update the policy on the workstation and open
the printer and faxes window, the "access denied" error has been
removed and the status is Ready.

This implies that the problem is corrected, however allowing access to
spoolss via anonymous access is considered a security
risk and the security team may not allow this to be modified. To
confirm whether not having this set would cause the problem
I moved the workstation back to the original OU.

The domain policy was applied and the Network Access: Named Pipes that
can be accessed anonymously - Enabled = " ", was set
back to a null value. I confirmed on the workstation and the registry
key
HKLM\System\CurrentControlSet\lanmanserver\parameters\NullPipeSessions
was set to Null (was enabled but value was blank).

However if I go back to the Printers window, the status of the printer
is still "Ready". When I add new printers I am unable
to get an Access Denied error again.

What I fail to understand is that originally this configuration caused
an error,. once I change to allow spoolss it commenced
working, but when I changed it back to original settings it doesn't
break again.

Can someone confirm for me whether you need the spoolss named pipe to
allow network printing to work correctly. If you do
not, any suggestions on why the "Access Denied" error occurs and how it
can be fixed.

Much Appreciated
Anthony.
 
The default installation configuration will work and you will not get access
denied.

You are 100% correct
I believe this issue may be caused because the spooler service on the
print server is unable to communicate successfully with
the spooler service on the workstation.
Click to expand...

here are some KBs regarding this behavior

http://support.microsoft.com/default.aspx?scid=kb;en-us;162695
SMSINST: "Access Denied" Error Message When You Try to Connect to a Shared
Network Printer

needs to be set to 1
http://support.microsoft.com/default.aspx?scid=kb;en-us;246261
How to Use the RestrictAnonymous Registry Value in Windows 2000

http://support.microsoft.com/default.aspx?scid=kb;en-us;823659
Client, service, and program incompatibilities that may occur when you
modify security settings and user rights assignments


NullSessionPipes needs to contain the spoolss value in order for the spooler
on the server to send job data to the client. The clients can still print,
but the notifications and queue status gets blocked by the client.



--
Alan Morris
Windows Printing Team
Search the Microsoft Knowledge Base here:
http://support.microsoft.com/default.aspx?scid=fh;[ln];kbhowto

This posting is provided "AS IS" with no warranties, and confers no rights.
 
Thanks for the reply Alan,

However I'm somewhat confused because currently all my workstations are
getting a policy applied that sets Network Access: Named Pipes that can
be accessed anonymously - to a NULL value. However it seems some all
workstations can still print but only some receive the "Access Denied"
error.

For those that do, I have tested moving them into a seperate OU and
applying the individual setting that allows SPOOLSS and the problem is
fixed.

So I can then assume that this setting overcomes the issue.

However enabling anonymous access to the Named Pipe may be a security
risk and therefore the Security team will not change the setting
without valid reason. Is setting access to SPOOLSS going to cause a
security vulnerability??

Due to my mixed results - i cannot confirm if the setting is required.
Should accessing a remote printer give me the "Access Denied" error if
the server cannot access the SPOOLSS on the client?

Cheers
Anthony
 
If the client can authenticate the spooler call from the server (if the
machine account of the server and the client are in the same domain or the
client user has administrative privilege on the server) then the call will
succeed with authentication. I have seen this fail if the spooler is
restarted on the client.

I normally assume the call comes in anonymous when I see a $ on the print
server name in the Shared Folders \Sessions on the client. I have not
debugged this to determine if this is true.

Open File Accessed By Type # Locks Open Mode
\PIPE\spoolss STRESSPR12$ Windows 0 Write+Read
\PIPE\spoolss _PRTPMC Windows 0 Write+Read
\PIPE\spoolss STRESSPR1$ Windows 0 Write+Read
\PIPE\spoolss NTPRINT$ Windows 0 Write+Read

All clients can print, they are not the ones who are getting denied access.
The SERVER is getting denied access to the client and this information is
displayed when opening the queue view.
Due to my mixed results - i cannot confirm if the setting is required.
Should accessing a remote printer give me the "Access Denied" error if
the server cannot access the SPOOLSS on the client?
Click to expand...

Yes you are always going to block the spooler on the server from sending
data to the client at some point with this configuration.

Regarding your question from previous post. Once the spooler from a server
has anonymous authentication, this will stay in affect until the spooler is
restarted on the client or the server.
"What I fail to understand is that originally this configuration caused
an error,. once I change to allow spoolss it commenced
working, but when I changed it back to original settings it doesn't
break again."

Is setting access to SPOOLSS going to cause a
security vulnerability??
Click to expand...
I hate to answer this one since I am not a security guru. Currently the
user calls to the print server and the print server just responds but gets
access denied on the return call since the spooler process of the server is
running in system context. The call is initiated from the client, the
server is attempting to satisfy this request.

There is a policy that will block RPC connections to the client spooler that
should mitigate a malicious application.
Computer\Administrative Templates\Printers\Allow print spooler to accept
client connections.

One can also configure the firewall with File and Printer Sharing exception
disabled (unless of course you need file sharing for the clients).



--
Alan Morris
Windows Printing Team
Search the Microsoft Knowledge Base here:
http://support.microsoft.com/default.aspx?scid=fh;[ln];kbhowto

This posting is provided "AS IS" with no warranties, and confers no rights.
 
Back
Top