Single forest, multiple domain, group rights...

[Tom]

Hello -

I have just set up a second domain within my company's forest. I
shall call call the domains RESOURCE and USER. I seem to be having
issues with the users (in USER) accessing the resources on RESOURCE.
Specifically, I am trying to have the users create/access their
roaming profiles off of a file server in the RESOURCE domain.

According to a document I found on Microsoft's web site I created a
local domain group on the RESOURCE domain and a Global group on the
USER domain. I placed the global group within the local group and I
receive an error saying the user doesn't have access to his folder. I
checked the share permissions and the local group has full access. I
checked his specific folder permissions and he has full access.

Originally, we attempted to create a universal group on the USER
domain and give that full permissions to the share but that didn't
work either. I thought that universal groups allowed me to create
permissions on any resource within a domain but Microsoft's
documentation that I found didn't discuss it.

So, can anyone give me some insight into what I am doing wrong and
secondly if I can use universal groups to set permissions on resources
outside it's own domain.

Much appreciate.

(e-mail address removed)

 

[Herb Martin]

Hello -

I have just set up a second domain within my company's forest. I
shall call call the domains RESOURCE and USER. I seem to be having

It would be better to use the actual names or at least close
analogies since these names above are likely to cause you
problems and in general we need to know if they are internal
only names or public names.

First: Single tag names like RESOURCE, rather than at least
two tag names like Resource.local or Resource.com present
problems for AD and DNS.

You problem is almost certainly a DNS issue anyway so this

issues with the users (in USER) accessing the resources on RESOURCE.

There has to be a way for each set of users (or usually their DNS
servers) to find the OTHER domain DNS name resolution.

Specifically, I am trying to have the users create/access their
roaming profiles off of a file server in the RESOURCE domain.

This (likely) is just a specific result of the overall name resolution
problem.

According to a document I found on Microsoft's web site I created a
local domain group on the RESOURCE domain and a Global group on the
USER domain. I placed the global group within the local group and I
receive an error saying the user doesn't have access to his folder.

That is correct (group placement) and the problem is still likely
with the names resolution and/or problems such causes with
authentication.

(Also note any user currently logged on would need to log on
anew for their membership in the Global group to be updated
in their credentials but this is unlikely to be part of your overall
problem.)

I
checked the share permissions and the local group has full access. I
checked his specific folder permissions and he has full access.

Originally, we attempted to create a universal group on the USER
domain and give that full permissions to the share but that didn't
work either. I thought that universal groups allowed me to create
permissions on any resource within a domain but Microsoft's
documentation that I found didn't discuss it.

So, can anyone give me some insight into what I am doing wrong and
secondly if I can use universal groups to set permissions on resources
outside it's own domain.

DCDiag all of your DCs and describe to us your DNS resolution methods.

Either you are running a common internal Parent domain, e.g., user.com
and resource.user.com, or company.com with user.company.com and
resource.company.com OR you must arrange for some method for the
DNS services in one domain to find the DNS servers in the other.

Most common solutions for the latter are:

1) Cross secondaries (DNS servers "for" each zone hold a copy of
the DNS zones of the other domain.)
The following are only available in Win2003
2) Conditional forwarding
3) cross Stub zones (pretty much the same as cross secondaries
except for the replication issues.)


DNS
1) Dynamic for the zone supporting AD
2) All internal DNS clients NIC\IP properties must specify SOLELY
that internal, dynamic DNS server (set.)
3) DCs and even DNS servers are DNS clients too -- see #2

Since each client must point to their "own" DNS servers, those
DNS servers much be able to resolve names from the "other"
zone -- either directly or through recursion and/or forwarding.

Ensure that DNS zones/domains are fully replicated to all DNS
servers for that (internal) zone/domain.