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.
Q: How can I administer my NT domain from a non-NT-based client?
You can use the respective Windows NT Server Tools to administer user accounts, machine services, Dynamic Host Configuration Protocol (DHCP) and WINS servers, and Remote Access Servers. For WFW and NT Workstation, these tools are on the NT Server 3.51 CD in the \clients\srvtools directory. To install the tools, run the Setup program or batch file from the respective directory. Windows NT Server Tools for Win95 are on the NT 3.51 Resource Kit CD in the \w95admin directory. To install the tools, double-click Add/Remove Programs from the Control Panel. To install and run License Manager on an NT workstation, copy llsmgr.hlp, llsmgr.exe, and llsrpc.dll from a computer running NT Server 3.51 to any directory on the NT workstation.
Q: What's a Security Identifier (SID), and what's the big secret?
An SID is a unique value that combines a domainwide ID and a relative identifier (RID) to identify each object in the domain (user, group, and computer accounts). The system assigns an SID to each user at logon.
That SID becomes part of the access token that accompanies any process the user starts. Except for the logon SID, an SID is unique--you can't reuse an SID after you use it to identify a user or group.
To identify users to the system, a system administrator creates user accounts by assigning usernames to new user accounts. NT generates an SID for each new account. The system stores this information in the Security Accounts Manager (SAM) database in the NT Registry.
An SID contains a 48-bit identifier authority value, a revision level, and a variable number of subauthority values (relative identifiers). The identifier authority, which is the most important piece of an SID, contains two values: one that identifies the agency that issued the SID, usually a Microsoft server domain, and a 32-bit RID that uniquely identifies the user or group in that agency. Joining these values ensures that no two SIDs will be the same, even if two different SID-issuing authorities issue the same RID. Each SID-issuing authority issues a given RID only once.
S-R-I-S is a standardized shorthand notation to help visualize an SID's components. In this notation, "S" identifies the series of digits as an SID, "R" is the revision level, "I" is the identifier-authority value, and "S" is the subauthority value. You can write an SID in this notation as S-1-4138-86. In this example, the SID has a revision level of 1, an identifier-authority value of 4138, and a subauthority value of 86.
getsid is a utility in the Windows NT Resource Kit for comparing the domain SID of one controller with another. The system acquires a domain controller's domain SID only during installation. All controllers in a domain need the same domain SID.
Q: How do I know which license mode to choose for my server?
Applications such as NT File and Print Services, Systems Management Server (SMS), SQL Server, and SNA use a license logging service. Such applications can register in one of two modes: per server and per seat. Use the per-server mode to control concurrent connections to the application and the per-seat mode to track each seat connection to the application. A seat allocation differs depending on the application it registers with. For example, NT File and Print Services register a seat as a user account, and SMS registers a seat as an SMS ID. The per-seat mode is more cost effective in many system configurations because a seat is typically connecting to multiple servers at once. If you configure per server, this seat occupies multiple licenses.
Administering an application's licenses in per-server mode consists of updating the license count on any server you purchase additional licenses for. You can update this count remotely through the License Manager application.
Administering applications' licenses in per-seat mode requires more attention than per-server mode. When purchasing additional per-seat licenses, you add the licenses to an application. This addition applies to any server in the domain. Because you are purchasing per-seat licenses for applications and can't specify the seat that you want a license associated with, you must control the seat allocation of licenses after the license logging service has recorded the connection. You use License Manager when you're looking at seat properties in the per-seat tab (that is, the user account for Windows NT File and Print Services or the ID for SMS). You can revoke seats that you deem not allocated to the licenses you have purchased.
Microsoft didn't intend to provide this level of management, and it becomes problematic in large environments, especially when a nonintuitive value, such as SMS ID, identifies the seat. If several SMS IDs change, the system will log them as new seats.
To solve this problem, the system administrator must run a report on all existing systems, print a list of current SMS IDs, and go into the License Manager application to revoke all the old SMS IDs.
Q: How can I use the %servername% environment variable?
The %servername% variable lets you improve load balancing and performance. A systems administrator can spread the load of processing user profiles to another server by setting the %SERVERNAME% environment variable to the name of a domain controller close to the workstation. When users log in to the domain, the domain controller directs them to the appropriate server, \\%servername%.
To expedite logon, the profile server needs to be near the client's computer (not across a slow link). For example, for all workstations in Phoenix, Arizona, set the variable to a server name in Phoenix. On workstations in Seattle, Washington, set the variable to a server name in Seattle. That way, when users are in Phoenix, their profile loads from a domain controller in Phoenix. When users visit Seattle, their profile loads from a controller in Seattle.
When you configure a user's profile path in User Manager for Domains on a domain controller, the entry is
UserProfiles
User Profile Path: \\%SERVER NAME%\profiles\user1.usr
You need to set the environment variable on the workstation computer, not the domain controller.
- Log on to the domain as Administrator.
- Run the Registry Editor (regedt32.exe), and select the workstation's computer name from the list.
- Be sure to select the hkey_local_machine of the workstation you have connected to, not your computer's hkey_local_machine.
- Go to hkey_local_machine\system\currentcontrolset\control\session manager\environment.
- Select AddValue, create: SERVERNAME=server1 (for example). Make sure SERVERNAME is of the type reg_sz.
- Exit the Registry Editor, and reboot the workstation.
- Open User Manager on a domain controller.
- Edit a user account, for example user1. In the Profile, set the User's Profile Path to \\%servername%\share\user1.usr. Make sure a shared directory is on server1.
- Exit User Manager.
- Enter the User Profile Editor.
- Select the user, user 1, who can access this profile.
- Make the appropriate changes.
- Save this information to a file and place it on \\server1\share.
- Have the user log on to the domain.
The profiles must reside in a shared directory. In this example, the share name of the directory \profiles is "share." You must perform these steps for every server that participates. This example involves only one server (server1).
Q: Why do I received Error 3013, "The redirector has timed out to SERVERNAME," in my System Log?
Possible causes are that the server you are trying to connect to is unavailable, very busy, or too far away to respond before the redirector timed out; the physical network cable is unavailable or very busy; or the network has a bottleneck.
The first step in troubleshooting such a problem is to verify that network protocol communication is functioning properly. With TCP/IP, you can use the ping utility to determine response time and Time to Live (TTL) and the tracert utility to evaluate specific routing characteristics.
After you verify the network protocol communication, you can test the connections between the client and the server. You can perform a network trace of the packets on the network to locate the root of the problem (look at the amount of time it takes for the server to respond to the workstation). You can also use Perfmon on the server (see the Windows NT Resource Kit, Volume 4, Chapter 7 to see how to detect network bottlenecks). You can try undoing any recent changes in network configuration. Also, if you were connecting to Machine B from Machine A, try connecting to Machine A from Machine B. Or you can have another client try to connect to the same server to see whether both redirectors have the same problem connecting.
After exhausting all troubleshooting options, you can try to increase the sesstimeout Registry parameter under hkey_local_machine\system\currentcontrolset\services\lanmanworkstation\parameters. sesstimeout specifies the maximum time the redirector lets a short-term operation be outstanding. The redirector uses this value to establish the extra time to wait for the Server Message Block (SMB) response. You can roughly calculate the time that the redirector actually waits for a server to respond to an SMB. The following formula will produce that value.
\[(SMBsize + size of data sent or received) / bytes per second\] + sesstimeout
This systemwide parameter applies to all protocols, including TCP/IP. However, sesstimeout doesn't apply to certain types of SMBs such as transaction commands that have their own timeout variable in the SMB.
Q: What are the hardware recommendations for a domain controller?
The following recommendations are for systems that function only as logon servers. If the system will run server-based applications or act as a file or print server, consider the additional resources those processes will require.
Table 1 shows guidelines for selecting a computer for use as a Primary Domain Controller (PDC) or Backup Domain Controller (BDC). For information on PDCs and BDCs, see Ed Tittel and Mary Madden, "PDCs, BDCs, and Availability," on page 75.
Q: How many user accounts can a domain support?
A domain consists of built-in and custom user accounts, machine accounts,
and group accounts. Each object occupies space in the SAM file. The practical
limit for the size of the SAM file depends on the type of computer processor and
amount of memory available in the machine that administers the domain. Microsoft
has successfully tested SAM files in excess of 40MB and recommends 40MB as the
upper limit (larger SAM files can take several minutes to load into memory for
administration purposes). Different types of objects require different amounts
of space in the SAM file. Table 2 shows examples of how to distribute objects in
one domain. For more information on domain planning, refer to http://www.
microsoft.com/backoffice
or the NT Server Forum on the Microsoft Network (GO WORD: MSNTS).
\[Editor's Note: For more on these issues, see Windows NT Magazine technical support forums at http://www.winntmag.com, Microsoft TechNet, CompuServe's WINNT forum, America Online's Windows NT area, The Microsoft Network, and Microsoft's Internet servers--http://www.microsoft.com and ftp://ftp.microsoft.com. The Microsoft Knowledge Base is at http://198.105.232.4:80/isapi/fts.dll?db=KB_winnt&qu=&qu=nt&mh=20.\]
| TABLE 1: Guidelines for Selecting a Domain Controller | |||||||||||
| SAM File Size | Number of User Accounts* | Minimum CPU Needed | Recommended RAM+ | ||||||||
| 5MB | up to 3000 | 486DX/33 | 32MB | ||||||||
| 10MB | 7500 | 486DX/66 | 32MB | ||||||||
| 15MB | 10,000 | Pentium, MIPS, Alpha AXP, PPC | 48MB | ||||||||
| 20MB | 15,000 | Pentium, MIPS, Alpha AXP, PPC | 64MB | ||||||||
| 30MB | 20,000-30,000 | Pentium, MIPS, Alpha AXP, PPC | 128MB | ||||||||
| 40MB | 30,000-40,000 | Pentium, MIPS, Alpha AXP, PPC | 166MB | ||||||||
| *User account numbers are approximate--exact SAM file sizes depend on the number of user accounts, machine accounts, group accounts, descriptions, full names, home directory and profile path information, etc. | |||||||||||
| +RAM should be at least 2.5 times the size of SAM. | |||||||||||
| TABLE 2: How to Distribute Objects in One | |||||||||||
| Configurations | User Accounts (1KB) | Machine Accounts (0.5KB) | Group Accounts (4KB) | Total SAM Size | |||||||
| 1 workstation per user | 2000 | 2000 | 30 | 3.12MB | |||||||
| 2 workstations per user | 5000 | 10,000 | 00 | 10.4MB | |||||||
| 2 users per workstation | 10,000 | 5000 | 150 | 13.1MB | |||||||
| 1 workstation per user | 25,000 | 25,000 | 200 | 38.3MB | |||||||
| 1 workstation per user | 40,000 | 0 | 0 | 40MB | |||||||
| You can apply these numbers to domains that comprise a single-master and multiple-master domain. | |||||||||||
| Contact Info |
|
Microsoft * 206-882-8080 Web: http://www.microsoft.com/supportnet |
