Q: Why do I get an "access denied" message when I try connecting
to resources on a Windows NT system, although I set up shared permissions with
Full Control to everyone?
In the validation algorithm, a client tries to connect to an NT-based
computer by transmitting domain name, username, and password user credentials.
If the username has the user right to access the NT computer from the network,
the system compares the user credentials with its local user account database.
If the system finds a match, it allows access.
If the system doesn't find a match and if the computer the client is trying
to access is a member of a domain, the system passes the client's user
credentials to a domain controller in the computer's domain. If the passed
domain name matches the domain controller's domain, the domain controller
compares the client's user credentials with information in the controller's
account database. If the domain controller finds a match, it allows access.
If the domain controller doesn't find a match, it checks whether the
client's domain name is a trusted domain. If so, the domain controller passes
the client's user credentials to a domain controller in that trusted domain;
this process of passing the client's credentials to a trusted domain is called
passthrough authentication.
If no match or trusts exist, the system checks the guest account of the
computer the client is trying to access. If the guest account is active, the
system allows access.
After the client establishes a session with the NT computer, share and NT
File System (NTFS) file permissions play an important role in controlling
resource access. The combined access rights of the shared resource are most
restrictive. So even if the file permissions grant access to everyone, if the
users don't have permission, they won't get in.
Some clients such as Windows for Workgroups (WFW) 3.1, Workgroup Connection
1.0, MS-DOS LAN Manager 2.0, and Microsoft OS/2 LAN Manager 2.0, 2.1, and 2.2
send null domain names when establishing a session. Only the server these
clients are trying to connect to can handle these session requests because the
null domain will cause passthrough authentication to fail.
To fix this problem, make sure the passwords and usernames at each stage
are correct, that accounts in the domain exist, that trusts are enabled, and
that appropriate access rights and permissions are associated with the desired
resources. For information on network security, refer to the Windows NT
Resource Kit, Volume 2, Chapter 4.
Q: I can't set up a trust or join or synchronize my domain, although I can
browse and connect to it. Why won't a domain controller validate me across a
router?
The usual reason for this problem is that network protocol communication is
not functioning properly. With TCP/IP, you can use the ping utility to verify
communication with the router and the remote domain controller. Also the tracert
utility can help determine whether client requests are reaching the other side
of the WAN device and whether a domain controller response is returning to the
client side of the WAN device.
You can browse and connect to the remote resource, so the problem is
probably related to NetBIOS name resolution. Most system administrators don't
set up routers to forward broadcasts. With TCP/IP, you can forward broadcasts by
disabling b-node broadcasts (User Datagram Protocol--UDP--ports 137 and 138). If
you disable these ports, you still need to be able to send a directed datagram
(a packet directed toward a specific destination NetBIOS name) to the domain
controller to communicate across a router. You can send directed datagrams with
a NetBIOS Name Resolution, such as the Windows Internet Name Service (WINS), or
an lmhosts file.
If you use WINS, make sure you have a registered domain name and include
the respective domain controllers' TCP/
IP addresses. Most Domain Name
Systems (DNSs) strip the NetBIOS extension in the sixteenth byte of the name, so
simply enabling DNS might not correctly resolve the domain name. If you've
configured your client for WINS, make sure it can query the WINS server to
resolve the remote domain controllers' IP addresses.
If your client doesn't use WINS, you can configure a WINS client on the
same subnet as a WINS proxy to forward UDP name resolution broadcasts to a
remote WINS server. If WINS isn't in your environment, you can send directed
datagrams by including a dom statement in an lmhosts file. For syntax, refer to
\systemroot%\system32\drivers\
etc\lmhosts.sam on your NT-based system. Save
this file as lmhosts without an extension. lmhosts file locations for non-NT
clients are \win95 for Windows 95, \windows for WFW, \net for Microsoft Network
Client, and \lanman.dos\etc for LAN Manager.
To communicate with a remote domain controller using Internet Packet
eXchange (IPX) and Sequenced Packet eXchange (SPX), configure a router to
forward Type 20 packets. For detailed information on networking with TCP/IP,
refer to the Windows NT Resource Kit, Volume 2, Chapter 12.
Q: Why can I administer the domain but receive an "access denied"
message when performing local administrative functions?
The credentials you supplied probably don't have sufficient permissions on
your local machine. In a domain, a member of the Domain Admins, or
Administrators, group on your NT domain controller can perform administrative
functions such as managing the user account database, managing shares, and
managing services on the domain controllers. However, having these domain rights
doesn't imply you have administrative rights on your local machine.
If your local machine is a domain controller in the domain, you can
administer your local machine because domain controllers have only one user
account database for verifying permissions. Each NT workstation and nondomain
controller server has its own user account database, separate from the domain
account database. Because of this separate account database, a user logged on to
the network must be a member of the local Administrators group to administer the
local machine. If users log on to the network with a domain account, they must
be members of the local Administrators group to perform local administration. To
add a domain user to the local Administrator's group, follow these steps:
- At the logon dialog, select the local computer name in the From
box, and specify a local administrator account and corresponding password.
- Open User Manager.
- Select the Administrators group.
- Click the Add button.
- Select the domain name in the List Names From field.
- Add the domain user(s) and group(s) that you want.
By default, when an NT Workstation or Server that is not a domain
controller joins a domain, the system adds a Domain Admins global group to the
computer's Administrators local group to let the domain administrators manage
that computer. The system also adds the Domain Users group to the computer's
Users local group.