syntax53MemberSep 05, 2015 at 9:17 pm #165730
We are just starting to use 2008 print servers this year and thought everything was working until we started noticing issues with standard users from different domains within the same forest not being able to connect to printers. e.g. Say we have root domain A with child domains B and C. If a 2008 DC on domain B is a print server, standard users from domains A and C could not connect to the printers. We found out that it wasn’t that they didn’t have access to connect (they did via the print server security properties) it was that they didn’t have access to download the drivers from the server. We found that the c:windowssystem32spooldrivers folder did not have the correct permissions to allow the clients to grab the drivers from the \serverprint$ share. So we added the permissions to the driver folder and thought we were on our way.
Now at this point some standard users from different domains could print and others couldn’t. We aren’t quite sure if it’s printer or driver related, but we had a user from domain C logged on to a computer joined to domain B trying to print to printers via a domain B domain controller + print server. We found the user could print fine to at least two other printers, but one in question was not working. AND… one that they could print to was the same driver and model as one that they couldn’t print to. The one that wasn’t working would either not print at all (no error displayed — it would just go in and out of the print queue) or it would print but a blank page would come out.
We started to get more call about these issues and have been investigated further. We know it’s a permissions issue because administrative users from different domains don’t have any problems. Standard users from the same domain also don’t have any problems. And with the 2003 servers (also domain controllers and print servers at the time) we never had any problems.
I started running process monitor on the 2008 server while I was trying to print with the users that weren’t working. What I found was there were access denied’s being thrown around for various DLLs in the windows directory. c:windowssystem32version.dll for example. I also saw some registry blocking occurring as well. After many many hours and banging my head against a wall and doing an slew of various google searches (thinking it was something obvious) and kept coming up blank. What I just found now after comparing the permissions between a 2003 domain controller and a 2008 DC was that the c:windows directory on the 2003 has the built in “Authenticated Users” group in the ACL as does the registry. The 2008 server does not. That authenticated users group gives forest-wide authenticated users read access to those files and registry entries. Also, if the server wasn’t a DC then it would have the local SERVERusers group which seems to do the same thing. However, since it’s a DC and only has the DOMAINusers group, users outside of the domain don’t seem to have access.
Only solutions I see are to add Authenticated Users to the ACL of the registry and windows directory (which is much easier said then done) or maybe adding the “DOMAINdomain users” group from every domain to every other domain’s “DOMAINusers” group. I don’t know if that’s possible but the window’s UI seems to let me do it. More importantly, I’m sure that’s not very good practice at all. And more to the point, I’m sure someone else has had to come across this before so why am I finding nothing about it on the internet.
Help Please and Thank You :)
You must be logged in to reply to this topic.