Two logon processes can start logon authentication:
Interactive logon occurs when the user types information in the Logon Information dialog box displayed by the computer's operating system. In Domain, the user selects either the name of a domain or the name of the computer being used for logon, depending on where the user account being logged on to is defined. If the computer is a member of a workgroup and not of a domain, the Logon Information dialog box does not have a place for typing in the domain name.
The following table compares the logon options for a user on a computer running Windows NT in a workgroup, in a domain, and in a domain with a trust relationship. The unique identifier used by Windows NT after logon depends on the location of the database used to log on the user. The third column in this table describes the unique identifier used in each case. Any network connection requests sent elsewhere on the network include this unique identifier.
Table 2.5 Summary of Interactive Logon Authentication
Computer is in | User can logon at | Unique identifier | |
Workgroup | Local database | Computername and username | |
Domain | Local database | Computername and username | |
Domain | Local database | Computername and username | |
Domain without a trust relationship | Local database | Computername and username | |
Remote logon takes place when a user is already logged on to a user account and makes a network connection to another computer. For example, the user connects to another computer using the Map Network Drive dialog box or the net use command.
A security-access token created at interactive logon is assigned to the initial process created for the user. When the user tries to access a resource on another computer, the remote server authenticates the user again and creates a security-access token for the user. The security-access token is placed in a table stored on the remote server. The server creates a user identifier (UID) for the user and maps it to the user's security-access token. This UID is sent back to the client redirector and is used in all further server-message-block (SMB) communication between the server and client. Subsequently, whenever a request for any resource on that server (and not just in the same share)comes in from the client, the UID identifies the user to the server process. The server checks the table and uses the security-access token stored for the UID.
For example, if a user attempts to connect to \\Myserver\share, a table entry on \\Myserver is set up with the user's SID. This is mapped to the user's access token. Later, if the user attempts to access a share called \art on \\Myserver, the original table entry will be used. The server examines the user's SID, locates an existing table entry, and validates (or denies) access to the files by comparing the access-token information to the access rights of the user. The attempt is successful in this example because the user had already established read access with the connection to \\Myserver\share.
If the user attempts to update information on \\Myserver\art and does not have write access to the share, access is denied. Even if the user is added to a group with write permissions, access will be denied because the one table entry still contains static information about the user's SID. The user must log off and log on again to create a new table entry. Then, the user will be able take advantage of the group's write permissions.
The server process creates a SID for the user and maps it to the user's security-access token. This SID is sent back to the client redirector and is used in all further server message block (SMB) communication between the server and client. Whenever a resource request comes in from the client, the SID identifies the user to the server process. The security-access token that maps to the user ID identifies the user to the remote security subsystem.
Figure 2.2 Remote logon authentication
The steps in a successful remote logon at a computer running Windows NT Workstation or Windows NT Server are:
1. The client computer sends the username, password, and domain name (the data entered in the Begin Logon dialog box) of the user to the remote Windows NT server.
2. The authenticating server compares the logon username and password with information in the user-accounts database.
3. If access is authorized, the server's LSA constructs an access token and passes it to the server process, which creates a user ID that refers to the access token.
4. The user ID is then returned to the client computer for use in all subsequent requests to the server.
After the session has been created, the client computer sends requests marked with the user ID it received during session setup. The server matches the user ID with the access token in an internal table. This access token at the server is used for access authentication.
The steps in a successful, remote logon at a Workgroup computer connecting to a computer running Windows NT in a domain are:
1. The local directory database performs interactive logon for the user at the workgroup computer (the client).
2. The client's username and a function of the password are passed to the specific server in the domain to which the client is trying to connect. This server checks the username and password with information in its local directory database. If there is a match, access to this server is allowed.
The steps in a successful remote logon at a domain computer connecting to a computer running Windows NT in the same domain are:
1. The domain's directory database performs interactive logon for the user at the client computer.
2. The client's domain name, username, and a function of the password are passed to the computer being accessed, which passes them to a computer running Windows NT Server in the domain.
3. The computer running Windows NT Server verifies that the domain name for the client matches this domain.
4. The computer running Windows NT Server checks the username and password against the domain's directory database. If there is a match, access is allowed.
The steps in a successful remote logon at a domain client in a trusted domain connecting to a Windows NT computer are:
1. The domain's directory database performs interactive logon for the user at the client computer.
2. The client's domain name, user name, and a function of the password are passed to the computer being accessed. That computer passes the logon information to a Windows NT Server in the domain.
3. The computer running Windows NT Server verifies that the client's domain is a trusted domain and then passes the client's identification information to a computer running Windows NT Server in the trusted domain.
4. A computer running Windows NT Server in the trusted domain (that is, in the same domain as the client computer) checks the user name and password against the domain's directory database. If there is a match, access is allowed.