Troubleshooting Unwanted \\"Access Denied\\" Messages in Domain-Based Networks (Windows NT 3.x and 4.0)

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

By Kip Gumenberg, Microsoft Support Engineer

Abstract

This white paper is meant to help you troubleshoot unwanted Access Denied messages when they occur in a Windows NT 4.0 domain environment. This information may also help with Windows NT 3.x.

Access Denied messages are a feature of Microsoft operating systems to indicate that users have attempted to access resources they should not access. Sometimes the network environment is not properly configured, and Access Denied messages appear even though the users are supposed to have access to those resources. Because today's operating systems are quite sophisticated, Access Denied messages may appear for many different reasons. This white paper is designed to help you troubleshoot unwanted Access Denied messages in Microsoft domain-based networks running Windows NT 3.x and 4.0 domain configurations. For your reference, this paper includes a glossary of terms used. For information on troubleshooting unwanted Access Denied messages in Microsoft workgroup-based networks, please refer to the "Troubleshooting Unwanted 'Access Denied' Messages in Workgroup-Based Networks."

This white paper is not meant to be a replacement for the Windows NT manuals. You are expected to know the difference between a Windows NT domain and Windows NT workgroup, and have a basic understanding of trusts and so forth. For more information, see the Windows NT 4.0 online documentation (by clicking Help on the Start menu).

This white paper discusses:

• File and share permissions.

• Trust relationships.

• Accessing a Windows NT domain computer when it is disconnected from the network where the primary domain controller (PDC) is located.

• Changing passwords (article 125575, "Access Denied Error When Changing Expired Domain Password," in the Microsoft Knowledge Base).

• Account validation (article 103390, "Network Access Validation Algorithm and Example," in the Microsoft Knowledge Base).

Access Denied messages appear in many more situations than this white paper can possibly describe. Please search for other articles on the topic in the Microsoft Knowledge Base.

Note: TechNet includes the Microsoft Knowledge Base.

File and Share Permissions

Incorrectly configured file and/or share permissions may prohibit users from accessing a file. In the following example, a user named Bob is trying to access a file called "Sales Report.txt" that is located on the \\ResearchDomain\\Docs share. When trying to open this file using Notepad.exe, Bob receives the following message:

The first step to begin troubleshooting this problem is to examine the permissions for the \\researchpdc\\docs share. You can do this by right-clicking the shared directory in Explorer and clicking Sharing on the shortcut menu. The following dialog box shows the permissions for the \\researchpdc\\docs share:

The dialog box above shows that the Managers and Supervisors global groups have Full Control access to the \\researchpdc\\docs share. Bob is a member of the Managers group, which indicates that the share permissions are not the cause of the access denied message. The next step is to examine the file permissions on the "Sales Report.txt" file.

The screen above shows that only the Supervisors global group has permissions to access this file. Because Bob is a member of the Managers group, but not the Supervisors group, Bob cannot access this file.

Bob's network administrator can resolve this problem in any of three ways: by granting the Managers group permission to this file, by adding Bob to the Supervisors group, or by giving Bob direct access permissions.

Trust Relationships

You can establish trust relationships between domains so that the domains share user account information. A secure channel is established between a domain controller (DC) in the trusting domain and a DC in the trusted domain. The secure channel ensures that only servers with the proper access rights can send and receive privileged information. Primarily, the trusting DC uses the secure channel to pass validation requests to the trusted domain controller. For more information, see article 128489, "Inter-Domain Trust Account Passwords," in the Microsoft Knowledge Base.

Non-existent trust relationships may cause Access Denied messages with User Manager for Domains and Server Manager. The following example shows the Trust Relationships dialog box from User Manager for Domains. You can open this dialog box by clicking Trust Relationships on the Policies menu. These dialog boxes show that the domains are configured for a one-way trust relationship, where SALESDOMAIN trusts RESEARCHDOMAIN. This trust relationship allows users from REASEARCHDOMAIN to access resources in SALESDOMAIN.

If users from SALESDOMAIN use User Manager for Domains and click Select Domain on the User menu and select RESEARCHDOMAIN, the following message appears:

A similar message appears if a user from SALESDOMAIN uses Server Manager then tries to click Select Domain and select RESEARCHDOMAIN.

To allow users from both SALESDOMAIN and RESEARCHDOMAIN to manage each domain's resources, two one-way trusts must be established from User Manager For Domains. This is done by clicking Trust Relationships on the Policies menu, and configuring the domains as shown in the following pictures:

Accessing a Windows NT Domain Computer When It is Disconnected from the Network Where the PDC Is Located

If you have a Windows NT computer that participates in a trusted domain structure that is sometimes disconnected from the main network, you may experience problems accessing that computer from another computer when the computer running Windows NT is disconnected from the main network.

For example, suppose a field engineer has two computers. One computer runs Windows NT and participates in a trusted domain. The other computer runs Windows for Workgroups. The computer running Windows for Workgroups is connected to the Windows NT computer, but the computer running Windows NT is not connectedto the main network. Accessing the Windows NT computer from the Windows for Workgroups computer may result in an Access Denied error message. This message occurs because the Windows NT computer looks for the domain controller when it is accessed. If the Windows NT computer is disconnected from the network, it cannot find a domain controller, so it returns the Access Denied error message.

When you are not connected to the main network, you can change the Windows NT computer to be a member of a workgroup instead of a member of a domain. You can do this by using Control Panel Network.

When the Windows NT computer is a member of a workgroup, it will not look for the domain controller. Keep in mind that you must have a user with the permissions you want defined in the local account database, or this procedure will not work.

Don't forget to rejoin the domain you were in when the Windows NT computer is reconnected to the main network. For more information, see article 108505, "Disconnecting from a Trusted Domain Network," in the Microsoft Knowledge Base.

Changing Passwords (125575)

When you attempt to change your expired domain password from a client workstation, the Access Denied error message appears. This problem occurs when "Users Must Log On In Order To Change Password" is selected in the User Manager for Domains Account Policy dialog box.

The default Windows NT Server configuration does not have "User Must Log On In Order To Change Password" selected. A system administrator must modify the user account for the person receiving the Access Denied error message by either assigning a new password or clearing the "User must log on in order to change password" check box.

Account Validation (103390)

The following is a simplified algorithm that explains how Windows NT Advanced Server account validation is observed to function during network access. With this information, you can predict Windows NT network logon behavior under deterministic conditions.

Keep in mind when following this article that the local database is the ONLY database on a domain controller. But on the other server and all workstations the local database is different than the domain controller.

Note: All references to Windows NT Advanced Server in this article also include Windows NT Server.

When two Microsoft network systems communicate over a network, they use a high-level protocol called server message block (SMB). These commands are embedded within the transport protocols like NetBEUI or TCP/IP. When a client carries out a NET USE command, it sends out a "SMB Session Setup and X" frame.

In Windows NT, the Session Setup SMB includes the user account, a function of the encrypted password and login domain. An Advanced Server will look at all of this information to determine if the client has permissions to complete the NET USE command.

Windows NT workstation sends the following command to an Advanced Server:

NET USE x: \\server\share

The Windows NT client sends a Session Setup SMB that contains its Login Domain, User Account and Password. The Advanced Server checks the SMB specified Domain name If the domain is the Advanced Server's own Domain then:

It checks its own Domain SAM[Security Account Manager]database for
a matching account.
If  it finds a matching account then
The SMB password is compared to the Domain Database password.
If  the password matches then
The Command Completed Successfully.
If  the password does NOT match then
User is prompted for a password.
It is retested as above.
System error 1326 has occurred.  Logon failure: unknown
user name or bad password.
End
If  it does NOT find the account in the domain SAM database then
Guest permissions are tested.
If  the Guest account is Enabled
The Command Completed Successfully.
If  the Guest account is Disabled
* See Note A.
User is prompted for a password.
System error 1326 has occurred.  Logon failure:
unknown user name or bad password.
End

If  the Domain specified in the SMB is one that the Advanced
Server TRUSTS then
The Advanced Server will do pass through authentication.  The
network logon request will be sent to an Advanced Server in the
specified Trusted Domain.

The Trusted Domain Advanced Server checks its own Domain database
for a matching account.
If  it finds a matching account then
It looks to see if the Account is a Local or Global Account.
If  the Account is Local then
Guest permissions on the Original Server are tested.
If  the Guest account is Enabled
The Command Completed Successfully.
If  the Guest account is Disabled
* See Note A.
User is prompted for a password.
System error 1326 has occurred.  Logon failure:
unknown user name or bad password.
End
If  the Account is Global
The SMB password is compared to the Domain Database
password.
If  the password matches then
The Command Completed Successfully.
* See Note B.
If  the password does NOT match then
User is prompted for a password.
It is retested as above.
System error 1326 has occurred.  Logon failure:
unknown user name or bad password.
End
If  it does NOT find the account in the Trusted domain
database then
Guest permissions are tested on the ORIGINAL Advanced
Server -NOT the Trusted Advanced Server.  * See Note C.
If  the Guest account is Enabled
User will have original server guest access.
The Command Completed Successfully.
If  the Guest account is Disabled
* See Note A.
User is prompted for a password.
System error 1326 has occurred.  Logon failure:
unknown user name or bad password.
End

If  the Domain specified in the SMB is UNKNOWN by the Advanced
Server. [A Domain was specified but it was not
recognized by the Server as a Trusted Domain or
its own.]
It  will check its own Domain Account Database for
a matching account
If  the Advanced Server finds a matching account then
The SMB password is compared to the Domain Database password.
If  the password matches then
The Command Completed Successfully.
If  the password does NOT match then
The User is prompted for a password.
It is retested as above.
System error 1326 has occurred.  Logon failure: unknown
user name or bad password.
End
If  it does NOT find the account in the domain database then
Guest permissions are tested.
If  the Guest account is Enabled
The Command Completed Successfully.
If  the Guest account is Disabled
System error 1326 has occurred.  Logon failure:
unknown user name or bad password.
End

If  the Domain specified in the SMB is NULL [None specified] then
The Advanced Server will treat this a local network logon.  It
will check for a matching account in its own SAM Database.
If  it finds a matching account then
The SMB password is compared to the SAM Database password.
If  the password matches then
The Command Completed Successfully.
If  the password does NOT match then
The User is prompted for a password.
It is retested as above.
System error 1326 has occurred.  Logon failure: unknown
user name or bad password.
End
If  it does NOT find the account in the local SAM Database then
The Advanced Server will Simultaneously ask another Advanced
Server in each Domain that it Trusts if it has account that
matches the SMB account.
The first Trusted Advanced Server to reply is sent a request to
perform pass through authentication of the client
information.
The Trusted Advanced Server will look in its own SAM Database.
If  an account that matches the SMB account is found then
It looks to see if the Account is a Local or Global
Account.
If  the Account is Local then
Guest permissions on the original Server are tested.
If  the Guest account is Enabled
The Command Completed Successfully.
If  the Guest account is Disabled
The user will be prompted for a password.
No matter what password is entered, user will receive
"Error 5: Access has been denied."
End
If  the Account is Global
The password specified in the SMB is compared
to the SAM Database password.
If  the password matches then
The Command Completed Successfully.
If  the password does NOT match then
The User is prompted for a password.
It is retested as above.
System error 1326 has occurred.  Logon failure:
unknown user name or bad password.
End
If  no Trusted Domains respond to request to identify the
account then
Guest permissions are tested on the Original Advanced Server -
not the Trusted server.
If  the Guest account is Enabled
The Command Completed Successfully.
If  the Guest account is Disabled
System error 1326 has occurred.  Logon failure:
unknown user name or bad password.
End

1. At the point that the GUEST account is disabled and the user does not have an account, the Windows NT Server will still request a password. Although no password will meet its requirements, it will still request it. This is a security measure. It insures that an unauthorized user cannot tell the difference between a case where an account exists and when the account does not exist. Password prompting always occurs regardless if the account exists.

   At this point, the following information is returned from the Trusted Domain in the Response: Domain SID, User ID, Global Groups Memberships, Logon Time, Logoff Time, KickOffTime, Full Name, Password LastSet, Password Can Change Flag, Password Must Change Flag, User Script, Profile Path, Home Directory and Bad Password Count.

   • Guest account only matters in the domain of the Server you are attempting to access. Guest accounts on trusted domains never come into play.

   • All steps above assume Global Account unless specified as Local Account. See the "Concepts and Planning Guide" for more information on account types.

   • The actual internal process is more complicated than the steps described above.

     A function of the One Way Encrypted password is sent.

   • The above model assumes that the Guest Account, when enabled, has no password. This is the default in Windows NT. If a guest account password is specified, it must match the users password that sends in the SMB.

Example

-------

The following are examples of this algorithm in action:

I am logged on to my Windows NT workstation local computer. I am using the same account name and password that is in SCRATCH-DOMAIN Advanced Server Domain account database. When I carry out the NET USE \\SCRATCH (Domain Controller for SCRATCH-DOMAIN) command, the command completes successfully. When I carry out the NET USE \\NET (Controller that Trust SCRATCH- DOMAIN) command. I receive the error message "System error 1326 has occurred. Logon failure: unknown user name or bad password." My account \SCRATCH-DOMAIN\USER1 has permissions on \\NET? What is the problem?

Configurations

--------------

Windows NT workstation:

• Login account: USER1

• Password: PSW1

• Login Domain: LOCAL1

Windows NT Advanced Server:

• Server Name: NET

• Advanced Server Domain: NET-DOMAIN

• Trust: NET-DOMAIN Trust SCRATCH-DOMAIN (Therefore, accounts on SCRATCH-DOMAIN can be granted permissions in the NET-DOMAIN.

• Domain Account Database for NET-DOMAIN does NOT contain an account for USER1.

• Guest Account is DISABLED.

Windows NT Advanced Server:

• Server Name: SCRATCH

• Advanced Server Domain: SCRATCH-DOMAIN

• Domain Database contains account: USER1

• Domain Database contains password: PSW1

Answer

------

In this example, the Windows NT workstation is logged on to its local workstation domain--not the Advanced Server SCRATCH-DOMAIN where its domain account resides.

NET USE x: \\NET\share

• When the Windows NT workstation carried out the NET USE x:\\NET\share command, it sent out account = "USER1", password = "PSW1" and domain = "LOCAL1" in the Session Setup SMB.

• The Advanced Server \\NET received the SMB and looked at the account name.

• It looks in its local domain account database and does not find a match.

• \\NET then looks at the SMB Domain name.

• It does not trust "LOCAL1" so it does not check any of its trusted domains.

• \\NET then checks its Guest account.

• The guest account is disabled so the "System error 1326 has occurred. Logon failure: unknown user name or bad password." message is generated.

NET USE x: \\SCRATCH\share

• When the Windows NT workstation carried out the NET USE x:\\SCRATCH\share command, it sent out account = "USER1", password = "PSW1" and domain = "LOCAL1" in the Session Setup SMB.

• The Advanced Server \\SCRATCH receives the SMB and looks at the account name.

• It looks in its local domain account database and finds a match.

• \\SCRATCH then compares the SMB password to the Domain account password.

• The passwords match so the "Command Completes Successfully" message is generated.

In these cases, the trust relationship does not come into play. If the Workstation had been logged on to the SCRATCH-DOMAIN, the NET USE x: \\NET\share command would have been successful.

The real answer here is to have all workstations log on to an Advanced Server domain. In order to login, the user must specify their correct domain, account, and password. After this is done, all NET USE type commands will pass the correct domain, account, and password. Administrators should try and avoid duplicate accounts on both Windows NT workstations and multiple Advanced Server domains.

USER: Workaround

----------------

There is one workaround that can be used in these cases. From the Windows NT workstation, you could carry out the following command

NET USE X: \\NET\SHARE /USER:SCRATCH-DOMAIN\USER1 PSW1

where

• \\NET = The computer name of the Advanced Server being accessed.

• \SHARE = The share name.

• /USER: command line parameter that lets you specify the domain, account and password that should be specified in the Session Setup SMB.

• SCRATCH-DOMAIN = Domain name of the Advanced Server where the user account resides.

• \USER1 = account to be validated against.

• PSW1 = password that matches account on the domain.

For more information, type the following at a Windows NT command prompt:

NET USE /?

NULL Domain Names

-----------------

In addition to Windows for Workgroups 3.1, other Microsoft network clients also send NULL Domain Names in the Session Setup SMB [x73]. They will also exhibit the behavior described above in the example problem. The following is a table of how each client handles the Domain Name.

MS Network Client	Domain Name Specified
Windows for Workgroups 3.1	NULL
Windows for Workgroups 3.11	Logon domain name.
MS OS/2 LAN Manager 2.0, 2.1, and 2.2	NULL
MS-DOS LAN Manager 2.0	NULL
MS-DOS LAN Manager 2.1 & 2.2 (Including Windows on MS-DOS)	Logon domain name. * See Note below.
Windows NT 3.1	Logon domain name.

Notes

-----

The default domain name is specified in the LANMAN.INI file on the "DOMAIN =" line. This can be overridden by the /DOMAIN: switch with the NET LOGON command.

There are typically two representations for "NULL" in the SMB: A zero-length domain name and a one-byte domain name consisting of the character '?'. The Windows NT SMB server catches the '?' and translates it to NULL before passing it to the local security authority (LSA).

Troubleshooting

---------------

A good tip for troubleshooting network access problems is to enable auditing by doing the following:

1. In the User Manager for Domains window, choose Audit from the Policies menu.

2. Select the Audit These Events button.

3. Select the Logon and Logoff Success and Failure options.

Now, anytime a network user access this server remotely, an audit trail will be logged in the Event Viewer. In the Event Viewer, choose Security from the Log menu to see the events.

Glossary

The directory database

Modern network server operating systems track user accounts in a secure and replicated database called a directory. The operating system services that facilitate the use of this database are called directory services.

Every Windows NT computer has a directory database that contains security information such as user account names and passwords. This directory database is sometimes also referred to as the user accounts database. Windows NT either shares the directory database information (in the case of domain configurations), or manages the directory database independently per computer (in the case of computers configured as workgroup members and also in the case of domain member servers).

Workgroup

A Windows NT workgroup is a collection of computers that are grouped for viewing purposes that do not share a common directory database. Windows NT workgroup directory databases must be managed individually, which increases the amount of time spent on user administration. For this reason, Windows NT workgroups are better suited for smaller sized networks.

Domain

The Windows NT Server domain is the administrative unit of Windows NT Server Directory Services. Within a domain, an administrator creates one user account for each user. The account includes user information, group memberships, and security policy information.

Through the domain structure, Microsoft Windows NT Server Directory Services provide several key advantages:

• Single user logon: Network users can connect to multiple servers with a single network logon. Directory Services extend this logon to all Windows NT Server services and server applications.

• Centralized network administration: A centralized view of the entire network from any workstation on the network provides the ability to track and manage information on users, groups, and resources in a distributed network. This single point of administration for multiple servers simplifies the management of a Windows NT Server-based network.

• Universal access to resources: One domain user account and password is all the user needs to use available resources throughout the network. Through Directory Services, account validation is extended to allow seamless user access to multiple network domains.

Although Windows NT Server Directory Services are invisible to you, they respond when you use Windows NT Server commands to manage the user and group accounts in your domain.

Domain controllers

A computer running Windows NT Server performs one of three different roles when participating in a domain: primary domain controller (PDC), backup domain controller (BDC), or stand-alone server (member server).

Windows NT domain controllers are servers that store copies of the domain's directory database. There are two different types of domain controllers: primary and backup. The domain's master copy of the directory database is located on the PDC and is replicated to each of the BDCs periodically. A domain contains only one PDC, but can have one or more backup domain controllers.

Member servers

A Windows NT member server is a computer that runs Windows NT Server but is not a PDC or a BDC of a Windows NT domain. Member servers do not receive copies of the shared directory database, instead, member servers contain an independent directory database.

Access tokens

A Windows NT user is assigned an access token after successfully logging on to the network. The access token is used to identify the user whenever that person makes a resource request under Windows NT. The access token contains a user's security identifier (SID), the group IDs, and the user's rights. An access token is generated during the initial logon, as well as each time the user starts a new session to a remote computer. The access token is valid until the user disconnects from the remote server or logs off the network.

Trust relationship

A Windows NT trust relationship is a link between two domains that enables pass-through authentication, in which a trusting domain honors the logon authentications of a trusted domain. With trust relationships, a user who has only one user account in one domain can potentially access the entire network. User accounts and global groups defined in a trusted domain can be given rights and resource permissions in a trusting domain, even though those accounts don't exist in the trusting domain's directory database. Trust relationships are established using User Manager for Domains. After a trust relationship is established, an interdomain trust account in the directory database of the trusted domain is created. This account is like any other global user account, except that the trust account is used only by the PDC and is invisible in User Manager for Domains. This account is sometimes referred to as the LSA Secret.

Account domain

An account domain contains all or some of the user accounts that exist on a network. A large network may have multiple account domains. Account domains may also contain machine accounts. Account domains are trusted by one or more resource domains.

Resource domain

A resource domain is a domain that contains only machine accounts. Resource domains are used to give network administrators the ability to manage their local resources without allowing the management of the user accounts within an organization. Resource domains always have a one-way trust relationship to one or more account domains.

Domain model

There are four basic different domain models:

• Single domain model: In this model, there is only one account domain, which also stores the computer accounts. No trust relationships are required.

• Master domain model: In this model, there is only one account domain, and one or more resource domains. All user accounts are stored in the account domain, and all resource domains have a one-way trust relationship with the single master domain.

• Multiple master domain model: In this model, there are multiple account domains and multiple resource domains. All resource domains have a one-way trust relationship with all account domains. User accounts are divided among the account domains only, where each account domain has two one-way trust relationships with each of the other account domains.

• Complete trust model: In this model, each domain has two one-way trust relationships with every other domain on the network.