Network access validation algorithms and examples for Windows Server 2003, Windows XP, and Windows 2000 (103390)

When Kerberos is used to authenticate the user and obtain access to server resources, the process is very different from what NTLM does. For more information, visit the following Microsoft TechNet Web site:

http://technet2.microsoft.com/WindowsServer/en/Library/f5c70774-25cd-4481-8b7a-3d65c86e69b11033.mspx

Remember that the local database is the domain database and the only database on the domain controllers. But on other servers and all computers, the local database differs from the domain controller.

Background information

When two Windows Server 2003-based, Windows XP-based, or Windows 2000-based computers communicate over a network, they use a high-level protocol called server message block (SMB). SMB commands are embedded in the transport protocols, such as NetBIOS Enhanced User Interface (NetBEUI) or TCP/IP. For example, when a client computer performs a NET USE command, an "SMB Session Setup and X" frame is sent out.

In Windows, the "Session Setup" SMB includes the user account, a hash function of the encrypted password and logon domain. A domain controller will examine all this information to determine whether the client has permissions to complete the NET USE command.

Algorithms

A Windows client computer sends the following command to a server:

   NET USE x: \\server\share

The Windows client computer sends a "Session Setup" SMB that contains its login domain, user account, and password.

The server examines the domain name or computer name that was specified by the SMB. If the name is the server's own name, the following algorithm is run:

    It checks its own domain database or computer database for
        a matching account.
    If it finds a matching account then
        The SMB password is compared to the domain database password or the computer 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.
                The password 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 Security Accounts Manager (SAM) database or computer 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).
            The 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 server trusts, the following algorithm is run:

    The server will do pass-through authentication. The
        network logon request will be sent to a server that has a domain controller role in the
        specified trusted domain.

If a secure channel is not set up, the following algorithm is run:

The trusted domain controller checks its own domain database
for a matching account.
If the trusted domain controller finds a matching account, then
NOT for Windows 2000 and later versions:
It determines whether 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) The 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 only option for Active Directory)
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
The user is prompted for a password.
The password is retested as above.
System error 1326 has occurred. Logon failure:
unknown user name or bad password.
End
If the trusted domain controller does NOT find the account in the trusted domain controller
database, then
Guest permissions are tested on the original server, not the trusted domain. (* See Note c)
If the guest account is enabled
The user will have original server guest access.
The command completed successfully.
If the guest account is disabled
(* See Note a) The 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 server, for example, if a domain was specified but was not recognized by the server as a trusted domain or its domain controller, the following algorithm is run:

    It  will check its own account database for
        a matching account
    If  the server finds a matching account, then
        The SMB password is compared to the domain database password or the computer 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.
                The password 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 that is specified in the SMB is NULL, that is, no domain is specified, the following algorithm is run:

The server will treat this a local network logon. The server
will test for a matching account in its own 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.
The password 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 AND
LsaLookupRestrictIsolatedNameLevel=0, then (* See Note d)
The server will simultaneously ask each domain that it trusts whether it has account that
matches the SMB account.
The first trusted domain to reply is sent a request to
perform pass-through authentication of the client
information.
The trusted domain will look in its own database.
If an account that matches the SMB account is found, then
The trusted domain determines whether the account is a local or global
account.
Not for Windows 2000 and later versions:
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.
Regardless of what password is entered, the user will receive
"Error 5: Access has been denied."
End
If the account is global (the only option for Active Directory)
The password that was 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.
The password is retested as above.
System error 1326 has occurred. Logon failure:
unknown user name or bad password.
End
If no trusted domains respond to the request to identify the
account, then
Guest permissions are tested on the original 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

Notes

If the guest account is disabled and the user does not have an account, the server will still request a password. Although no password will meet its requirements, the server will still request a password as a security measure. This security measure insures that an unauthorized user cannot tell the difference between a case where an account exists and when the account does not exist. The user will always be prompted for a password regardless of whether 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.
If no account is found on the trusted domain, the operating system must use the local guest account to guarantee consistent behavior for authentication against the server.
For more information about how to restrict the lookup of isolated names in external trusted domains by using the LsaLookupRestrictIsolatedNameLevel registry entry, click the following article number to view the article in the Microsoft Knowledge Base:
818024 How to restrict the lookup of isolated names in external trusted domains by using the LsaLookupRestrictIsolatedNameLevel registry entry

Guest accounts on trusted domains will never be available.
The actual, internal process is more complex than the algorithms that are described here.
These algorithms do not discuss the actual mechanics of pass-through authentication. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
102716 NTLM user authentication in Windows
These algorithms do not discuss the password encryption process that is used in Windows Server 2003, Windows XP, and Windows 2000. A binary large object (BLOB) derived from a one-way password hash is sent as part of the authentication request. The content of this BLOB will depend on the authentication protocol chosen for the logon.
This article does not discuss the internal workings of the Microsoft Authentication Module.
These algorithms assume that the guest account, when enabled, has no password. By default, the guest account does not have a password in Windows Server 2003, Windows XP, and Windows 2000. If a guest account password is specified, the user password that is sent in the SMB must match that guest account password.

Examples

The following are examples of these algorithms in action.

Example 1

You are logged on to the computer by using the same account name and password that is in the SCRATCH-DOMAIN domain account database. When you run the NET USE \\SCRATCH command for the domain controller for the SCRATCH-DOMAIN domain, the command is completed successfully. When you run the NET USE \\NET command for the domain controller that trusts the SCRATCH-DOMAIN domain, you receive the following error message:

System error 1326 has occurred. Logon failure: unknown user name or bad password.

The \SCRATCH-DOMAIN\USER1 account has permissions on \\NET.

Note This example assumes the following configurations.

Configurations

Computer that has a local security authority:

  -Login account: USER1
  -Password:      PSW1
  -Login Domain:  LOCAL1

Active Directory domain controller:

  -Server Name: NET</WWITEM>
  -Domain:      NET-DOMAIN</WWITEM>
  -Trust:       NET-DOMAIN Trust SCRATCH-DOMAIN (Therefore,
                accounts on SCRATCH-DOMAIN can be granted permissions 
                in the NET- DOMAIN).

The NET-DOMAIN domain:

The domain account database for the NET-DOMAIN domain does not contain an account for USER1.
The guest account is disabled.

Windows Server 2003:

  -Server Name:                       SCRATCH
  -Domain:                            SCRATCH-DOMAIN
  -Domain Database contains account:  USER1
  -Domain Database contains password: PSW1

In this example, the computer is logged on to its local domain, not the SCRATCH-DOMAIN domain where the computer's domain account resides.

Example 2

When you run the NET USE x: \\NET\share command, the following steps occur:

The computer sends out the following in the "Session Setup" SMB:
account = "USER1"
password = "PSW1"
domain = "LOCAL1"
The \\NET server receives the SMB and looked at the account name.
The server examines its local domain account database and does not find a match.
The server then examines the SMB domain name.
The server does not trust "LOCAL1," so the server does not check its trusted domains.
The server 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." error message is generated.

Example 3

When you run the NET USE x: \\SCRATCH\sharecommand, the following steps occur:

The computer sends out the following in the "Session Setup" SMB:
account = "USER1"
password = "PSW1"
domain = "LOCAL1"
The \\SCRATCH server receives the SMB and examines the account name.
The server examines its local domain account database and finds a match.
The server then compares the SMB password to the domain account password.
The passwords match. Therefore, the "Command Completes Successfully" message is generated.

In Example 2 and Example 3, the trust relationship is unavailable. If the computer had been logged on to the SCRATCH-DOMAIN domain, the NET USE x: \\NET\share command would have been successful.

The ideal solution is to have all computers log on to a domain. In order to log on, the user must specify the domain, account, and password. After you do this, all NET USE-type commands will pass the correct domain, account, and password information. Administrators should try to avoid duplicate accounts on both computers and multiple domains. Windows Server 2003-based, Windows XP-based, and Windows 2000-based computers help avoid this configuration by using trusts between domains and by using members that can use domain databases.

Workaround

There is one workaround that can be used in these cases. From the computer, you could run the following command:

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

In this command, the follow is true:

  - \\NET = The computer name of the domain controller 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 domain where the user
    account resides.
  - \USER1 = account to be validated against.
  - PSW1 = password that matches account on the domain.

For more information about this command, type the following at the command prompt:

NET USE /?

NULL domain names

The Microsoft SMB client that is included in Windows Server 2003, Windows XP, and Windows 2000 sends NULL domain names in the "Session Setup SMB [x73]" SMB. The Microsoft SMB client handles the domain name by specifying the logon domain name and by sending a NULL character if the domain name is not specified in the NET USE command. The Microsoft SMB client will also exhibit the behavior described in Example 1.

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 that consists of the question mark character (?). The SMB server catches the question mark 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.

Windows 2000 and later versions of Windows 2000-based domain controllers

From the Administrative Tools on a domain controller, start Active Directory Users and Computers.
Right-click Domain Controllers OU, and then click Properties.
On the Group Policy tab, double-click Default Domain Controller Policy.
In the Policy Editor, click Computer Settings, click Windows Settings, click Security Settings, click Local Policies, and then click Audit Policy.
Select the Logon and Account Logon Success option and the Failure option.

Domain settings for Windows 2000 servers and members

From the Administrative Tools on a domain controller, start Active Directory Users and Computers.
Right-click the domain name, and then click Properties.
On the Group Policy tab, double-click Default Domain Policy.
In the Policy Editor, click Computer Settings, click Windows Settings, click Security Settings, click Local Policies, and then click Audit Policy.
Select the Logon and Account Logon Success option and the Failure option.

Local settings for Windows 2000 servers and members

From the Administrative Tools, start Local Security Policy.
Open Audit Policy.
Select the Logon and Account Logon Success option and the Failure option.

Now, any time that a network user accesses this server remotely, an audit trail will be logged in Event Viewer. To see these events in Event Viewer, click Security in the Log menu.

For more information about trust relationships, pass-through authentication, user permissions, and domain logins, see the "Technical Overview of Windows Server 2003 Security Services." To do this, visit the following Microsoft Web site:

http://www.microsoft.com/windowsserver2003/techinfo/overview/security.mspx