Announcement

Collapse
No announcement yet.

2008 R2 print server permission issue for users in different domain

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • 2008 R2 print server permission issue for users in different domain

    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:\windows\system32\spool\drivers folder did not have the correct permissions to allow the clients to grab the drivers from the \\server\print$ 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:\windows\system32\version.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 SERVER\users group which seems to do the same thing. However, since it's a DC and only has the DOMAIN\users 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 "DOMAIN\domain users" group from every domain to every other domain's "DOMAIN\users" 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
    Last edited by syntax53; 6th September 2015, 04:41.

  • #2
    Long post with a lot of information in it. That is good to see.

    If I have read this correctly, you have 3 Domains or have you just used A, B & C as examples and you have more Domains?
    Are the Print Servers all on DCs?
    Is there any specific reason why you are using Server 2008 instead of 2008 R2 or later?
    No mention of what operating system the clients are using or whether they are desktops, laptops, Notebooks or Tablets (like Surface Pro). Have you noticed any correlation between the different O/S and hardware platforms?
    Have you considered virtualising the Print Servers on the Domains? If you have a problem where the PS needs rebooted it makes it a lot easier to do than if it is sitting on a DC.
    Are your Users in specific OUs or are they all lumped together in one OU?
    Have you considered using a GPO to assign the appropriate permissions for the clients to access the drivers?
    On the machines that can't access the drivers, can you browse from it to the PS? (\\servername\print$ )

    Hope you head is ok and the wall not too badly damaged.
    1 1 was a racehorse.
    2 2 was 1 2.
    1 1 1 1 race 1 day,
    2 2 1 1 2

    Comment


    • #3
      Thanks for the reply. I believe I found a fix (workaround?) but will answer all of your questions as well. The fix was to add the "Authenticated Users" group to each domain's local builtin Users group ("DOMAIN\Users"). We did this with the following command: net localgroup Users "Authenticated Users" /add ... Not sure if this is good practice or not but I think it achieves exactly what I would expect to be default behavior -- all users in the forest, no matter what domain they are in, are considered regular "users" in every domain.

      Originally posted by biggles77 View Post
      Long post with a lot of information in it. That is good to see.
      Thanks, I try

      If I have read this correctly, you have 3 Domains or have you just used A, B & C as examples and you have more Domains?
      No, we have 9 domains.

      Are the Print Servers all on DCs?
      Yes, they are.

      Is there any specific reason why you are using Server 2008 instead of 2008 R2 or later?
      We are using R2. Sorry, mentioned it in the thread title but didn't specify elsewhere.

      No mention of what operating system the clients are using or whether they are desktops, laptops, Notebooks or Tablets (like Surface Pro). Have you noticed any correlation between the different O/S and hardware platforms?
      All OS's are Windows 7 64-bit. We have some windows 8 and some windows 7 32-bit but did not test.

      Have you considered virtualising the Print Servers on the Domains? If you have a problem where the PS needs rebooted it makes it a lot easier to do than if it is sitting on a DC.
      Have not considiered.

      Are your Users in specific OUs or are they all lumped together in one OU?
      Most are in 1 OU, but a decent amount are in others for various reasons.

      Have you considered using a GPO to assign the appropriate permissions for the clients to access the drivers?
      Read bit about using GPO's to distribute printers but I wrote some custom scripts using kixtart to install the printers for us. Don't recall seeing anything about permission in there other than the point and print restrictions and allowing non-admins to install drivers which we have been doing for a couple years now.

      On the machines that can't access the drivers, can you browse from it to the PS? (\\servername\print$ )
      Before I added explicit permissions onto the drivers folder, no they couldn't.

      Hope you head is ok and the wall not too badly damaged.
      Head is fine. If only I could do something about these mosquito bites from labor day weekend though...

      Comment


      • #4
        Missed the R2 in the thread title. DOH!

        Why did you find it necessary to you kix :vomit: when a simple GPO can push the printer drivers out to the clients? (curiosity question only) It is well worth reading some more and trying it. GPOs are a real good time saver once you are even slightly familiar with them.
        1 1 was a racehorse.
        2 2 was 1 2.
        1 1 1 1 race 1 day,
        2 2 1 1 2

        Comment


        • #5
          You can use a GPO to allow your standard users to install the printers.

          http://answers.microsoft.com/en-us/w...7d4a550?auth=1

          Might not help but maybe worth a bash seeing as admin users are fine?

          Comment


          • #6
            Originally posted by biggles77 View Post
            Missed the R2 in the thread title. DOH!

            Why did you find it necessary to you kix :vomit: when a simple GPO can push the printer drivers out to the clients? (curiosity question only) It is well worth reading some more and trying it. GPOs are a real good time saver once you are even slightly familiar with them.
            We wanted very granular control over who gets what printers, more so than GPO seemed to offer at the time.

            Comment


            • #7
              Originally posted by wullieb1 View Post
              You can use a GPO to allow your standard users to install the printers.

              http://answers.microsoft.com/en-us/w...7d4a550?auth=1

              Might not help but maybe worth a bash seeing as admin users are fine?
              Point and print restrictions were already disabled. That was not the issue.

              Comment

              Working...
              X