RE: Permissions

From: ilene (
Date: 08/19/03

Date: Tue, 19 Aug 2003 10:01:38 -0700

Thank you for your wonderful directions, which I followed
but it's not working. Here's what I did...

I already have established but the trust relationships and
administrative permissions in each domain (Domainb.local
and domainc.local) Each DC from either domain (B or C) can
see and access all files and shares.

In Domainb I created the global group and assigned the
designated members to this group. In domainc where the
shares reside, I created a domain local group and placed
the global group from domainb in it.

On the shares, which are on the same partition as the OS
in domainc, I added the domainlocal group I created and
gave it permissions at the share of the file and in the
security of that file too.

I have a w2k machine that is part of domainb, it can
access any and all files from the DC from domainb. IT's
when I try to connect to the DC in DomainC that I have the
problem. If I click on Network neighboorhood, domainc,
domain controller c I get a message that no logon servers
are available to service the logon request.

To my knowledge I am following AGLP but I must be doing
something wrong.

Is a better discription?
>-----Original Message-----
>Hi Ilene,
>Thank you for the posting.
>As you described, you created a few shares and one DFS in
domainc and you
>are trying to access it from domainb. In domainc you
have created a local
>group and added the global group for domainb but when you
try to access the
>share from domainb it will not allow you access to any of
the shares.
>In order to better understand this issue, please let me
know the exact
>error message word for word when you are trying to access
the share.
>Please let me know if you can see the share correct.
>First, please make sure the two domains have trust
relationship. For a
>user in a trusted domain to access resources in a
trusting domain, perform
>the following steps:
>1. Create a global group in the trusted domain.
>2. Create a local group on the member server in the
trusting domain.
>3. Add the global group from the trusted domain to the
local group in the
>trusting domain.
>4. Assign permissions at the share and NTFS level to the
local group on the
>member server.
>Please check if the following symptoms apply to your
>Symptom 1. When attempting to administer resources (such
as user accounts
>through User Manager for Domains) in a trusting domain,
the administrator
>receives an access denied message.
>Symptom 2. On a member server in a trusting domain, an
administrator gives
>permissions to a local group of users, but members of
that group receive
>access denied messages when trying to access the resource.
>It is possible that the group memberships have not been
configured in a
>correct manner:
>Symptom 1 often occurs when the domain administrators
global group from the
>trusted domain has not been added to the local
administrators group in the
>trusting domain.
>Symptom 2 can occur because of insufficient share or NTFS
permissions, as
>well as incorrectly configuring the membership of a local
group in the
>resource domain.
>To Resolve Symptom 1
>After establishing a trust, the domain administrators for
a trusted domain
>are not automatically added to the administrators group
of a trusting
>domain. If the ability to administer the trusting domain
by members of the
>the trusted domain is desired, these members must be
manually added.
>To Resolve Symptom 2
>NTFS permissions and share permissions are separate
entities. Users must
>have sufficient permissions at both levels to access a
resource, because a
>process will be granted the most restrictive of the two
>Another possibility for this problem is because member
servers and
>workstations in a domain have separate accounts databases
from the domain
>controllers; for example, creating a local group on a
domain controller
>does not create the same local group in the accounts
databases of
>workstations and servers in the domain. That local group
would only exist
>in the SAM for the domain controllers. Likewise,
creating a local group on
>a workstation or member server only creates that local
group in that one
>computer's SAM.
>Furthermore, local groups on a member server cannot
include local groups
>from a domain controller. Interestingly enough, a common
mistake is to try
>to add a local group from a domain controller to the
access control list
>(ACL) on a workstation or member server. This can be
done by clicking
>Search in the Add Users and Groups dialog box.
Unfortunately, the result
>is essentially meaningless because a member of the local
group on a domain
>controller will still not be able to access a shared
resource through that
>type of group association.
>For more information on Configuring Share Permissions,
please refer to this
>knowledge base article:
>301198 HOW TO: Share Files and Folders Over a Network
(Domain) in Windows
>For more inforamtion on DFS Share, please refer to the
following knowledge
>base articles:
>272230 Error Message When You Attempt to Access a Domain-
Based DFS Share in
>Hope the above information and suggestion helps and
answers your question.
>If anything is unclear, please let me know.
>Cherry Qian
>MCSE2000, MCSA2000, MCDBA2000
>Microsoft Partner Online Support
>Get Secure! -
>When responding to posts, please Reply to Group via your
newsreader so
>that others may learn and benefit from your issue.
>This posting is provided AS IS with no warranties, and
confers no rights.