Permissions

[Ilene]

I have a setup of basically 3 domains in a forest. I have
the Hollowroot (toproot - which is the GC for the domain
and has the enterprise admin) followed by 2 other
domains. Lets call it domaina.com, domainb.local and
domainc.local. Domaina.com is the toproot and b and c are
the locals. I'm trying to apply permissions to folders.
I have created a few shares and 1 DFS in domainc and I am
trying to access it from domainb. In domain c I have
created a local group and added the global group for
domain b but when I try to access the share from domain b
it will not allow me access to any of the shares.

What am I doing wrong? I can see everything between
servers. I just can not access it from a 2000 machine
from domainb.

Help please?

 

[Cherry Qian]

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 situation:

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 permissions.

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
2000
http://support.microsoft.com/?id=301198

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
http://support.microsoft.com/?id=272230

Hope the above information and suggestion helps and answers your question.
If anything is unclear, please let me know.

Sincerely,

Cherry Qian
MCSE2000, MCSA2000, MCDBA2000
Microsoft Partner Online Support


Get Secure! - www.microsoft.com/security

====================================================
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.

 

[Herb Martin]

I have a setup of basically 3 domains in a forest. I have
the Hollowroot (toproot - which is the GC for the domain
and has the enterprise admin) followed by 2 other
domains.

In most senses, a GC is a forest wide role -- they can run on
any of the DCs within the forst, and depend mostly on the
placemet of DCs and your site architecture.

You should generally have 1+ GCs per AD Site (you might
be able to bend this rule in Win2003 but you need to review
the new features etc.)

Lets call it domaina.com, domainb.local and
domainc.local. Domaina.com is the toproot and b and c are
the locals. I'm trying to apply permissions to folders.
I have created a few shares and 1 DFS in domainc and I am
trying to access it from domainb.

You use the term "local" -- domains actually have "no location"
but are available anywhere your clients can contact services on
the network. Sites control issues of locality and you need a GC
PER SITE (usually).

In domain c I have
created a local group and added the global group for
domain b but when I try to access the share from domain b
it will not allow me access to any of the shares.

What "it"? What client apps are you using to test? Just
Explorer or Network neighorhood? Or are you testing
explicitly with "Net USE" and testing no explicit authentication
versus giving username and password.

By checking various combinations with Net Use you eliminate
or isolate problems of authentication, routing, name resolution,
etc.

What am I doing wrong? I can see everything between
servers. I just can not access it from a 2000 machine
from domainb.

What clients operating systems are you using and what
errors are you seeing explicitly?

 

[ilene]

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?

 

[Ilene]

I use local domains for description purposes only, as
in .local. The it is networkneighboorhood and when I open
network neighboorhood I can see the domain from the w2k
machine, I can open that, see the server name in domain c
and when I try to access that I get the error message that
\\servername\not accessible, there are currently no logon
servers available to service the logon request.

Hope this helps.

 

[Cherry Qian]

Hi Ilene,

Thank you for the posting again. As you described, it can access any and
all files from the DC from domainb. It's when you try to connect to the DC
in DomainC that exhibit the problem. You received a message that no logon
servers are available to service the logon request.

Based on your description and our further research, it apears the WINS
database does not have the proper domain registrations for pass-through
authentication. This problem occurs most often in environments where the
administrator has created a two-way trust between two previously
independent domains. Most often, there are WINS servers in each domain and
the WINS servers do not replicate their databases to each other.

To resolve this problem:

- Allow WINS dynamic registration. This ensures that Domain Controllers
register their DOMAIN<1C> NetBIOS names with the WINS Server.

- Make certain that WINS database replication is successful between WINS
Servers. Missing database entries for domain names may indicate Problems
with the WINS Servers and replication.

To work around this problem:

NOTE: Microsoft does not recommend using static mappings in the WINS
database for WINS enabled computers.

1. Run the WINS Administration Utility to add static mappings for the
Domain<1C> registrations (of the trusted domain) that are not listed in the
WINS database:

Name: Master DOMAIN Name
IP Address: Address of the Primary Domain Controller (PDC) of the
domain
Type: Domain Name

If you are logged on as an administrator at a Domain Controller, remote
administration works now successfully. If you are attempting to remotely
administer the domain while logged on to a Server (not a domain controller)
or Windows NT Workstation, you must add DOMAIN<1C> entries for both the
trusted and trusting domains.

To remotely administer a trusted domain, several pass-through
authentication steps must take place. If the WINS database does not have
the proper domain registrations, the pass-through authentication fails.

For example, a trust is established between DOMAIN_A and DOMAIN_B. Server
PDC_A is in DOMAIN_A and PDC_B is in DOMAIN_B. DOMAIN_A is the trusted
(master) domain, and DOMAIN_B is the resource (trusting) domain. To
establish this trust relationship, the following NetBIOS names must be
resolved to IP addresses, either through WINS or broadcast:

NetBIOS Name Description of Use of Name
---------------------------------------------------------------------
DOMAIN_A<1B> PDC_B uses this to query the PDC of DOMAIN_A
PDC_A<00> PDC_B uses this to set up a session with the PDC of
DOMAIN_A
DOMAIN_A<1C> PDC_B uses this to get DC list of DOMAIN_A

With these three names being registered, and if your account has
administrator priviledges, the trust can be established and the message
"The trust relationship was established successfully" appears. When you
reboot the computer, or the first time you attempt remote administration,
another NetBIOS name is needed:

NetBIOS Name Description of Use of Name
---------------------------------------------------------------------
DOMAIN_A<1C> Each Domain Controller in DOMAIN_B uses this name to
establish a secure channel with a Domain Controller in the trusted domain.

The Domain Controller (DC) in the trusting domain attempts to create a
secure channel with any DC in the trusted domain by making a multicast
logon request to the NetBIOS name DOMAIN_A<1C>. This logon request is part
of a process that creates a Secure Channel between the two DCs. The logon
ID in this logon request is the inter-domain trust account for the trusting
domain, DOMAIN_B$. If there is no registration for DOMAIN_A<1C> in the WINS
database the error message STATUS_NO_LOGON_SERVERS is returned to the call.
The message "There are currently no logon servers available" is then
returned to the user.

Hope the above information and suggestion helps and answers your question.
If anything is unclear, please let me know.

Sincerely,

Cherry Qian
MCSE2000, MCSA2000, MCDBA2000
Microsoft Partner Online Support


Get Secure! - www.microsoft.com/security

====================================================
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.

 

[Cherry Qian]

Hi Ilene,

Thank you for taking the time to let me know the results. I am glad to
hear my suggestion helped you to fix this issue.

If anything is unclear or if there is anything further we can help you with
from our side, please let me know.

It was my pleasure working with you on this issue. Have a nice day!

Sincerely,

Cherry Qian
MCSE2000, MCSA2000, MCDBA2000
Microsoft Partner Online Support


Get Secure! - www.microsoft.com/security

====================================================
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.

 

[Herb Martin]

It's usually a DNS issue. Required: Dynamic DNS,
servers (including DCs) AND clients configured to use
the dynamic DNS, and a GC in each site.