Cross Forest Printers

Question

I am trying to set up printers for users, and the print server is in a forest with a trust relationship. Users are all on Windows 7, and the print server is Server 2008 R2 Standard.

DomainA contains the print server DomainB contains the users

When users or admins in DomainB attempt to add printers from the DomainA print server, they get a generic error that says "Windows cannot connect to the printer. Access is denied"

I have added DomainB users to the DomainA printer security w/ print rights, still getting the same error. I've even tried creating a Domain Local group in DomainA, and added users from DomainB, and it still fails whether I'm using a standard user or a domain admin in DomainB.

When adding the printer via IP, it works, but that's not running through the print server and isn't an acceptable solution in our environment.

What do I need to do to get this cross-forest printing working?

ADDITIONAL INFO FROM TESTING: DomainB user is able to browse file shares on the DomainA print server, but adding printers flags the error. DomainB user was able to add certain HP/Brother printers, but Ricoh and Canon printers fail. All the printers they were able to add were printers who's drivers are included by default in Win7. This seems to only occurs when the print driver needs to be downloaded from the print server. Possible share missing or with wrong permissions?

Solution 1

I solved this issue by adding "DomainB\Domain Users" group to the "print$" share permissions on the printer server in DomainA. The DomainB user account can then read the driver folder contents, download and install the driver. The printer can then work as long as the trust is up and running so that the "Everyone" group functions on the printer security.

Solution 2

Check your GPO gpresult /z or gpresult /h on a failing machine under a failing user account and see if you have any Point and Print restrictions enabled in your Group Policy. If you do, you'll have to add the FQDN of the printer server in the other forest to the list.

Solution 3

It sounds like the Forest Trust is using Selective Authentication. If so, you need to grant DomainB users the "Allowed to Authenticate" permission on the print server computer object in ADUC in DomainA.

Comments

[Spence]

What kind of errors are you getting if you create a shared disk resource on the print server and attempt to access it as a user from the other Forest?

[MDMarra]

Do printers work from inside of your own forest as expected? When exactly do you get an access denied? Can you post a screen shot? I get the feeling this might be a Point and Print error and you're barking up the wrong tree.

[the-wabbit]

Also, can you use other resources (especially connect to shares) from the print server in the trusting domain?

[kralyk]

How are DomainB users printing currently? It sounds like there is already a print server in DomainB (according to your "acceptable environment"), so wouldn't it just be easier to create a printer object on DomainB's print server for the same printer that is on the print server in DomainA and just let DomainB users continue to use their own print server?

[Deep Kumar Singh]

DomainA users are in North America, and DomainB users are in Europe, so currently DomainB users don't have any printers unless they connect directly via IP.

[kralyk]

Did you check in the print server properties own security tab? I think it also needs rights there to "view server" and "print" for that domain local group, not just on the printer itself.

[Deep Kumar Singh]

Inside DomainA, all printing is working as expected, no issues. I'm currently trying to get access to the test machine again, but timezones and available personnel are an issue. Another piece I should mention, these users were migrated from DomainA to DomainB, so now their DomainB account has a secondary SID that is the old DomainA SID. I've also found that their computer accounts have the exact same names in both domains, the old computer account was never removed... I'm suspecting this might cause additional issues due to Event errors I'm seeing indicating kerberos ticket generation errors.

[Spence]

@MarkF: Yep-- the fact that you can access it by IP but not by name makes me immediately suspicious of something Kerberos-related, too.

[Deep Kumar Singh]

@Evan When we navigate to the file shares of the print server [\\printserver.domainA.com], it shows all printers and folders. Attempting to double-click on the printer from here gives the same error

[Deep Kumar Singh]

I've checked the trusts, both incoming and outgoing are using domain-wide authentication, not selective.

[joeqwerty]

You mentioned that the user accounts were migrated from DomainA to DomainB, do (or did) the UPN Suffix for the users migrate as well? I wonder if there's a UPN Suffix conflict?

[Deep Kumar Singh]

I've checked in the user's account tab in AD Users & Computers, they have the correct new domain suffix. Is there somewhere else I should check on this?

[Deep Kumar Singh]

There were NO Point and Print restrictions on this machine when I started troubleshooting. During troubleshooting I enabled the policy under Computer Config for this test machine and left everything blank and un-checked except for enabling the policy. They don't need this policy, should I remove for testing?