Home > Articles > Operating Systems, Server > Microsoft Servers

Managing the Directory

Like this article? We recommend

Like this article? We recommend

4.6: Logging On and Authentication

Logging On

One of the fundamental concepts of the Windows 2000 security model is the idea that a user must log on to a Windows 2000 computer before accessing any of its resources. By enforcing a mandatory logon, Windows 2000 prevents unauthorized users from accessing the system and can prevent authorized users from having more access than the computer's administrator wants them to.

Once logged on, the computer knows who the user is and can then provide or deny access as appropriate. In a Domain environment, access to resources can be allowed or denied to any security principal in the Domain—where a security principal is a either a user or a machine.

A Windows 2000 computer that is a member of a Domain logs on to the Domain at startup. It specifies its computer account and a password, which was set by the Domain Controller when the computer joined the Domain. The most familiar way users identify themselves to Windows 2000 is by typing in their username, entering their password, and specifying their Domain in the Log On to Windows dialog box. There are other ways, though. The usual prompt for username and password can be replaced by the use of smart cards or even biometric devices such as retinal scanners. You also log on to a computer when you access it from across the network; before it lets you do that, the computer has to identify who you are and check to see what access it should allow you to have.

UPNs for Logon

In Windows 2000, users can log on just as they can with Windows NT 4.0—by typing in their user name, entering their password, and selecting their Domain name. But users can also log on specifying their User Principal Name (UPN) and password. The UPN name is the concatenation of their username (the UPN prefix), the @ symbol, and the DNS name of their Domain (the UPN suffix). If a user, Rebecca, were in a Domain called Kapoho.com, her UPN name would be Rebecca@kapoho.com. Because this is also an email alias, using UPNs is easier than having to remember separate e-mail aliases and login IDs.

In a large enterprise with a deep Domain structure, the UPN name can be tiresome to type as well as error-prone. However, by using the Active Directory Domains and Trust tool, you can create additional UPN suffixes for your Domain. After these are created, you can use the Active Directory Users and Computers tool to modify the user's properties to allow them to use a different UPN suffix when logging in. If, in the example, Rebecca's account were in the Domain jasminehouse.uk.europe.kapoho.com, her default UPN would be Rebecca@jasminehouse.uk.europe.kapoho.com. If an administrator were to add the UPN suffix kapoho.com and adjust her account properties, she could log in as Rebecca@kapoho.com.

This section will primarily focus on how to configure and troubleshoot logging on to systems that are part of a Windows 2000 Domain.

Logging on basically consists of two main activities:

  • Authentication. Establishing the identity of the security principal (user or computer) that is requesting access to the computer.

  • Creation of the user desktop. Performing other routine tasks such as the processing of profiles, policies, and logon scripts to configure the user's environment.

What Happens After a User Enters a Username and Password?

For more information, see "Interactive User Logon" later in this chapter.

There are four ways in which security principals log on to Windows 2000 systems:

  • Computer Logon. Every Windows 2000 computer that is a member of a Domain logs on to the Domain at startup with its computer account, even before users log on.

  • Interactive User Logon. When you enter a username and password in the Log On to Windows box, you are performing an interactive logon.

  • Network User Logon. When you connect to a shared resource on a network server, Windows 2000 performs a remote logon to the server computer using the user's username and password.

  • Service Logon. Windows 2000 applications can be configured to run as services. Services log on to Windows 2000 computers without requiring a user desktop, but they do run with a specific user account.

These four types of logons are described in the following sections.

Not All Processes Log On

There are also processes that run in Windows 2000 that do not need to log on. They use the System built-in account.

For more information, see Chapter 1.1, "Overview of Windows 2000 Architecture."

Computer Logon

If a Windows 2000 system has been configured as a member of a Domain, the system contacts a Domain Controller for the Domain at startup in order to process policies that apply to the computer and to retrieve a list of trusted Domains. After this process is complete, the system can present a logon prompt for users to be able to log on interactively.

If the system is a member of a workgroup rather than a Domain, the computer does not need to perform a computer logon.

Requirements for Computer Logon

For a computer to log on to the Domain successfully, a Domain Controller for the computer's Domain must be available and the computer must have an account in the Domain.

For more information on computer accounts, see "Configuring a Windows 2000 System for Domain Member" later in this chapter.

Steps of the Computer Logon

When a computer logs on, the following steps occur:

  1. The system locates a Domain Controller for its Domain by querying a DNS server for the IP addresses of "close" Domain Controllers.

  2. The computer's account in the Domain is authenticated so the computer can perform the next two steps.

  3. The computer retrieves a list of trusted Domains.

  4. This list is used to build the list of allowed Domains for users to log on to that appears in the Log On to Windows box.

  5. The computer retrieves Group Policies that apply to the computer, processes them, and runs any startup scripts.

What Is a "Close" Domain Controller?

When contacting a Domain Controller, a Windows 2000 client, as noted previously, will attempt to contact a Domain Controller that is close, thus avoiding using WAN links. To do this, the client will look for Domain Controllers in the same Active Directory site as the client.

For more information on the way sites are defined in DNS, see Chapter 4.2, "DNS and Active Directory".

Troubleshooting Logon Problems

Troubleshooting logon problems, especially in a Domain environment can be complex and will vary with the client OS. If you fail to log in, interactively from a Windows 2000 client, some things to check include the following:

  • Is the client configured to access a DNS server that contains correct Active Directory SRV records for the target Domain?

  • Is that DNS server accessible?

  • Is there a Global Catalog server accessible from the Domain Controller that is attempting to authenticate the user?

  • If this is a Domain Controller, is the user a member of an Administrative group or has the policy for the Domain Controller been adjusted to allow other users to log in interactively?

  • As with Windows NT 4.0, is the user ID and password correct, and is the account active?

Interactive User Logon

An interactive user will perform an interactive logon in two ways: Pressing the Ctrl+Alt+Del key sequence and entering a username and password in the Log On to Windows box, or swiping a smart card through a smart card reader and entering a PIN. The system will authenticate the user, and if the authentication was successful, it will start a user shell with the user's personalized desktop settings.

To log on interactively to a Windows 2000 system, you must have a valid username and password, and your account must have been granted the Log on locally user right on the computer.

For more information on user rights, see Chapter 6.3,"Group Policies."

The steps in the logon process are shown in Figure 4.6.1 and described in the following list.

Figure 4.6.1 Logging on to a Domain.

  1. If the IP address of a Domain Controller was not cached previously, the client computer locates a Domain Controller by issuing a query to the DNS to locate a Domain Controller.

  2. If the DNS server has the appropriate records, they are returned to the client.

  3. The client then requests authentication by sending a logon request with the user name and password to the Domain Controller, which will verify the user name and password against the Active Directory and build a list of SIDs for the user relating to any local and global groups the user is a member of.

  4. The Domain Controller then sends a query to a Global Catalog server to determine universal groups to which the user belongs.

  5. The GC will respond with the SIDs for these universal groups the user is a member of, which the Domain Controller can then add to the list created in step 3.

  6. The Domain Controller provides a logon response to the client, which includes a list of all of the user's SIDs.

  7. The client computer examines its local policies to determine which rights the user should have on the local computer. Finally, the user's profile is loaded, Group Policies related to the logged on user are processed, and any logon scripts are run.

Requirements for User Logon to a Domain

  • A Domain Controller of the Domain must be available.

  • A Global Catalog server must be available.

  • The username and password must match the information stored in Active Directory.

  • The user must have the Log on locally user right for the computer.

If no Domain Controller is available, and the user has logged on to the Domain at that computer in the past, the user will be logged on with cached credentials. If you do not want credentials to be cached, you can disable this feature by using a Group Policy.

For more information on these objects, see Chapter 6.3 "Group Policies."

For more information about requirements for authentication in a multiple Domain environment, see "Going Deeper" later in this chapter.

Logging On Automatically at System Startup

You can configure a system to log on automatically with a specific user account whenever it is restarted. This is useful for kiosk computers or other special-purpose computers.

Be careful how you use this feature, though. You probably don't want to have your servers log on automatically. The account that you use and its password are easily visible to anyone who can access the Registry, so it's not very secure. You should be running your applications as services rather than interactively on your servers anyway, so there's no need to log on at the console.

Limit Automatic Logons

The best practice is to limit automatic logons to Windows 2000 Professional systems that will be used for public use. You should make sure that the account that you use has very limited access to resources on the computer or on the network. You certainly don't want to make the account a member of the Administrators group unless you like reinstalling the operating system when users mess it up!

To log on automatically at system startup, execute the following steps:

  1. Run regedt32 and navigate to HKEY_LOCAL_MACHINE\HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon.

  2. Double-click the DefaultDomainName and enter the Domain name.

  3. Double-click the DefaultUserName and fill in the default user name.

  4. Create a new string value named DefaultPassword and enter the user's password.

  5. Create a new string value named AutoAdminlogon with a datatype of REG_SZ and set this to a value of 1.

  6. Reboot and you should now automatically log in as the user you entered.

To stop the computer from logging on automatically, change the data for the Autologon value to No and restart the computer.

The username and password that you use to log on automatically are stored in the Registry. Anyone who can access the Registry at that computer, whether from the console or remotely, can see the username and password. Do not make the user account a member of the local Administrators group, and give the account minimal access to the computer.

Network User Logon

Whenever a user attempts to access a Windows 2000 computer's shared resources by connecting to a named share on the computer, the computer must first establish the user's identity before granting access to the share. This process is called a network user logon or remote logon.

For example, when you map a network drive to a shared folder on a file server, you need to log on to the computer before you can access the share. The network redirector performs this task for you automatically, using your current credentials.

  1. Authenticate the user. The steps to authenticate the user are different, depending on whether Kerberos or NTLM is being used.

    • If Kerberos, the client requests a service ticket for the remote server from the Domain Controller and then presents the service ticket to the remote server.

    • If NTLM, the client requests a NetBIOS session with the remote server, which then has to authenticate the user by querying a Domain Controller for the user account.

  2. Grant or deny access to the requested resource. The server checks the user's identity against the permissions assigned to the resource and against the user rights that have been granted to the user.

Service Logon

Applications can be run as services in Windows 2000, which allows them to run in their own user context with their own user account and password, independently of any interactive user session.

Windows 2000 comes with many standard services that start automatically when the system starts, such as the Server service and the Net Logon service. Other services are configured to start on demand. The user account that is used by the service is configured through the Computer Management console.

For more information about services, see Chapter 1.1, "Overview of Windows 2000 Architecture."

  1. Start the service. Services can be started by the local system at system startup by configuring them to start automatically. An administrator can also start and stop services by using one of the management tools or by using the net start and net stop commands.

  2. Authenticate the user. The username and password that is associated with the service is authenticated. The account must have the Log on as a service user right.

  3. Create a user context for the service on the computer. If a user environment for the user account does not already exist, a new user environment will be created. The service will be limited by the permissions and rights assigned to the service on that computer.

Configuring Systems to Log On to a Domain

Network clients can log on interactively to Windows 2000 Domains by using several different client operating systems. The steps for configuring the Domain logon for each operating system are described as follows.

Logging On to a Domain from Windows 2000

Before a Windows 2000 system can be configured as a Domain member, an account for the computer must exist in the Domain. Domain Controllers are already members of the Domain and require no additional configuration.

Joining a computer to a Domain has the following effects:

  • The DNS Domain name of the computer is automatically changed to be the same as the name of the Domain. For example, the computer called kona would have a TCP/IP hostname of kona.kapoho.com after joining the kapoho.com Domain.

  • At startup, the computer will log on to the Domain in order to retrieve a list of trusted Domains and to process Group Policy for the computer.

  • You can log on to the computer and be authenticated with an account from any Domain in the forest. User profiles, Group Policies, and logon scripts are retrieved from the network and processed.

  • You can grant permissions for resources on the local computer to users and groups from any Domain in the forest.

Best Practices for Adding Windows 2000 Computers to Active Directory Domains

  • Limit the number of people that can add computers to Domains.

  • Control the capability to add computers to the Domain by managing the permissions on the default Computers container in the Active Directory Domain.

  • Consider using Domain-wide OUs, filtered by group to control the specific permission to add computers to that Domain. For more granular control, you could create the GPO at OU level, thus delegating control to add computers to specific OUs to smaller groups of users.

  • Create an account specifically for creating computer accounts. Use this account when adding computers to the Domain. This is a good idea if you are performing scripted installations (which show the username and password in clear text) because the account will have only the minimum abilities required.

  • Use the NetDom Resource Kit utility to add computers to the Domain without having to visit individual desktops.

  • For larger organizations, also develop ASDI-based scripts to add computers.

  • For more information on modifying groups with ADSI, see Chapter 4.5, "Creating and Modifying Groups."

Configuring a Windows 2000 System as a Domain Member

Before you can configure a Windows 2000 system to log on to a Domain, you must meet these requirements:

  • A computer account must be added to the Domain. The computer account can be created in advance or at the time of joining the Domain. The user adding the computer to the Domain must have permission to create a computer object in the container in the Domain. By default, the Computers container at the root of the Domain is used, and Domain administrators have permission to create new computer objects in it.

  • The user adding the computer to the Domain must be a member of the local Administrators group on the computer.

  • A Domain Controller for the Domain must be available.

  • A Global Catalog server must be available.

You can move a Windows 2000 computer from one Domain to another by simply changing the settings in Network Identification in the Network option in Control Panel.

You cannot change the Domain membership of a Domain Controller. You must demote it by running dcpromo.exe before you can join the computer to a different Domain.

For step-by-step instructions, search for the "Join a Domain" topic in Windows 2000 Help.

Best Practices for Distributing Administration of Computer Accounts

The strategies for distributing administration depend on the size of your organization and whether authority for administration is centralized or delegated.

  • For small Domains, simply add the user or users responsible for account creation into the Domain Administrators group. For small Domains or for users who should have extensive authority, make them a member of the Domain Admins group.

  • To increase security, create a special Administrators account, which should be used only to perform account maintenance and give the password to that account to the individuals responsible for account administration. When administration activities are required, the user can either log in to the special account or use the RUNAS command to run the MMC with elevated privileges.

  • For moderate-sized Domain environments with centralized security, you can create a separate group to perform account maintenance. Just create a new Domain local group and add this group to the Domain administrators group for the Domain in which they can create users.

  • For a Domain environment with a decentralized administration, create a Domain local group for each OU or sub-OU who can create objects. Then, grant that group the right to create objects in the OU. Finally, add the users who will be carrying out the maintenance to the appropriate local group.

Logging On to a Windows 2000 Domain from Windows NT 4.0

Windows 2000 Domains appear like Windows NT 4.0 Domains to Windows NT 4.0 clients. When Windows NT 4.0 clients log on to a Windows 2000 Domain, they locate a Domain Controller by performing a NetBIOS name query (via WINS, lmhosts, or a broadcast). They then use the NTLM authentication protocol to authenticate the user or computer. System policies and logon scripts are retrieved from the Netlogon share of the Domain Controller.

If the Windows 2000 Domain is in Mixed mode, only the computer's Domain and the Domains that are directly trusted by that Domain will appear in the Domain list box in the Log On to Windows dialog box. If the Windows 2000 Domain is in native mode, all of the Domains in the Windows 2000 forest will appear as possible Domains to which they can log on.

Configuring a Windows NT 4.0 System as a Domain Member

Configuring a Windows NT 4.0 system as a member of a Windows 2000 Domain is no different from configuring it as a member of a Windows NT 4.0 Domain. As far as the system is concerned, the Windows 2000 Domain Controller behaves just like a Windows NT 4.0 Domain Controller.

Joining the Domain consists of two steps:

  1. Create a computer account. You can do this in advance by creating a computer object in the Computers container. You can also do it at the client by specifying the username and password of an account that is a member of the Domain Admins group in the Windows 2000 Domain or has the necessary permissions to create a computer object.

  2. In the Network option in Control Panel, change the name of the Windows NT 4.0 system's Domain to the Downlevel Domain name (NetBIOS name) of the Windows 2000 Domain that was assigned when the Domain was created. Usually, this is the leftmost part of the Domain's full DNS name. For example, if the Domain is called mcp.com, enter MCP as the Domain name.

After the required reboot, you'll be able to log on to the Windows 2000 Domain as if it were a Windows NT 4.0 Domain.

Logging On to a Domain from Windows 95/98

Windows 95/98 systems can either log on to the network as part of a workgroup or they can log on to a Domain:

  • Workgroup logon. The user specifies a username and password to use on the network, but no Domain Controller is contacted, and no user policies or user logon scripts are retrieved from the network.

  • Domain logon. The user specifies a username, password, and Domain name. The computer then locates a Domain Controller for the Domain and authenticates the user. If a system policy file (config.pol) is found in the Netlogon share of the Domain Controller, it is processed. If there is a user profile in the user's home directory or logon scripts associated with the user's account, they are processed, too.

Windows 95 and Windows 98 systems do not require a computer account in a Domain to log on.

Configuring a Windows 95/98 System for Domain Logon

You configure a Windows 95 or Windows 98 system to log on to a Windows 2000 Domain by changing the properties of the Client for Microsoft Networks.

Use the Network option in Control Panel to display a list of installed components. Set the Primary Network Logon to the Client for Microsoft Networks. Then, modify the properties of the Client for Microsoft Networks to include the name of the Domain and select the Log On to Windows NT Domain checkbox.

After you restart the computer, you will be prompted to supply your username, password, and Domain name whenever you log on.

Going Deeper: How a Windows 2000 System Authenticates a User

A Windows 2000 system authenticates a user by locating a Domain Controller and then using the appropriate authentication protocol to authenticate the user. The process is transparent to the user, except for the need to provide a username and password.

Why Go Deeper with Authentication If It Is Transparent to the User?

If you understand how authentication works in Windows 2000, it makes troubleshooting logon and authentication problems a lot easier! It also explains how trusts work in a multi-Domain network.

The purpose of the authentication process is for the user to prove to the system that the user should be allowed access. The computer authenticates the user (verifying his identity) and then builds an access token on the computer that contains all of the Security Identifiers (SIDs) that are associated with the user's account.

The computer will locate a Domain Controller by using either the Windows 2000 Resolver and DNS, or else by using the NetBIOS Resolver and NetBIOS name resolution.

Windows 2000 supports three authentication mechanisms: Kerberos, Windows NT LAN Manager (NTLM), and Secure Socket Layer/Transport Layer Security (SSL/TLS). The authentication protocol that is used depends on the application that is requesting access to the resource.

When logging on to a Domain, Windows 2000 clients use the Kerberos authentication protocol by default. They will, however, use NTLM if Kerberos authentication is not available (for example, when logging on to a Windows NT 4.0 Domain). NTLM is also used by Windows 2000 systems that are not members of a Domain.

Locating a Domain Controller

Windows 2000 systems use two different methods of locating Domain Controllers:

  • The Windows 2000 Resolver uses DNS (and the DNS cache) to locate Domain Controllers.

  • The NetBIOS Resolver uses queries for a NetBIOS service to locate Domain Controllers.

Windows 2000 systems try the Windows 2000 Resolver first, and will use the NetBIOS Resolver only if no Domain Controllers can be located by DNS.

The Windows 2000 Resolver

The Windows 2000 Resolver queries DNS for specific SRV resource records to locate Domain Controllers. The process is explained as follows:

  1. The client queries DNS for a list of Domain Controllers in its site. These Domain Controllers are identified in DNS as LDAP SRV records.

  2. The client sends an LDAP UDP query to port 389 on the Domain Controllers to identify which Domain Controllers are available.

  3. The client uses the responses to the query to determine the closest Domain Controller in its site. If no Domain Controllers respond, the client queries DNS for LDAP SRV records.

  4. The client attempts to locate one of them.

  5. The client sends its logon request to the Domain Controller.

The NetBIOS Resolver

If the Windows 2000 Resolver is unable to locate a Domain Controller via DNS, the NetBIOS Resolver is tried.

The NetBIOS Resolver queries the NetBIOS interface for entries for the Domainname <1B> NetBIOS name that identifies Domain Controllers. If the system is a WINS client, the WINS server is queried for Domainname <1B>, which provides a list of Domain Controllers in the Domain. The client will then connect with one of the Domain Controllers in the list. If WINS is not available or has no name registration records for Domainname <1B>, the client will broadcast to attempt to locate a Domain Controller.

Kerberos Authentication

Kerberos is an authentication protocol that provides for mutual authentication of clients and servers using an industry-standard protocol. Kerberos is based on shared secrets cryptography. Windows 2000 supports Kerberos version 5.

On Windows 2000 Domain Controllers, the Kerberos Key Distribution Center (KDC) service authenticates Kerberos clients. This service provides both the Authentication Service (AS) and a Ticket Granting Service (TGS) needed in Kerberos authentication. The KDC service is part of the Local Security Authority process of Windows 2000 (lsass.exe), uses Active Directory as its account database, starts automatically, and cannot be stopped.

In a nutshell, Kerberos authentication works as follows:

  1. When a user logs on, the client computer submits a request for authentication to the KDC (Domain Controller).

  2. If the request is successful, the KDC sends the client a Ticket Granting Ticket (TGT). This ticket is used as a session ticket for all communications with the KDC.

  3. Whenever the client needs to initiate a connection to a server (network logon), the client uses the TGT to request a session ticket for the server from the Ticket Granting Service (TGS) running on Domain Controller.

  4. If the client is allowed to access the server, the TGS sends a ticket back to the client.

  5. The client presents the session ticket to the server with which it wants to communicate. The server accepts the identity of the client because the ticket indicates that the user has been authenticated by a trusted authority (the Domain Controller). See Figure 4.6.2.

  6. Optionally, the server can identify itself back to the client.

Figure 4.6.2 Authentication in a single Domain.

Kerberos tickets are kept in a local cache and are aged. When they have expired, they cannot be used anymore. This forces the client to get a new ticket from the KDC when it needs to connect to a remote server. (Existing connections aren't affected by expired tickets, only attempts to create new connections are.)

How Do I Figure Out Which Tickets Have Been Issued to My Computer?

You can see which tickets have been issued to your computer by using the kerbtray.exe application from the Windows 2000 Resource Kit. You can also view Kerberos tickets by using the klist.exe console command.

The default length of time that Kerberos tickets are valid is eight hours, but you can modify this interval by using a Group Policy for the site, Domain, or Organizational Unit. Windows 2000 will flush the cache and destroy all existing tickets when a user logs off. Because Kerberos tickets are time-sensitive, it is very important to synchronize the system time on client computers with the Domain Controller. The Windows Time service automatically synchronizes the time among Domain Controllers in a forest.

Windows 2000 Domains are the equivalent of Kerberos realms. Cross-realm authentication occurs in Windows 2000 through the use of trust relationships. The Key Distribution Center Service account krbtgt is used to authenticate a Domain Controller when authenticating users or computers in other Domains.

Where Did Kerberos Come From?

The name Kerberos comes from the name of the three-headed dog that guarded the gates at the entrance to Hades in Greek mythology—like the three roles in Kerberos authentication: client, server, and Key Distribution Center (KDC).

The specification for the Kerberos protocol can be found in RFC 1510. Kerberos was originally developed at the Massachusetts Institute of Technology (MIT).

For more information, see http://www.mit.edu.

Single Domain Kerberos Authentication

The steps of authenticating a user whose account is in the same Domain as the computer is described in the following list:

  1. The user logs on with username and password. The client sends an authorization request to the KDC service on the Domain Controller.

  2. The Domain Controller queries the Global Catalog in order to include all group Security IDs (SIDs) associated with the user's account.

  3. The Domain Controller returns a Ticket Granting Ticket (TGT) to the client, which includes the SIDs of the user and the groups the user is in.

  4. The client uses the TGT to send a request to the Domain Controller for a session ticket for the user to the local computer.

  5. The Domain Controller returns a session ticket for the user to the local computer. The rest of the logon process can now continue (creating a user desktop, processing Group Policy, and so on).

As a result, you must have a Domain Controller and a Global Catalog server available to be authenticated in a Windows 2000 Domain.

Multiple Domain Kerberos Authentication

When there are multiple Domains in Active Directory, the process of authenticating a user can be more complex. When a Domain Controller receives an authorization request for an account that is not in its Domain, it generates a referral, which consists of a session ticket to a Domain Controller that has a better chance of being able to authorize the user.

Suppose you have three Domains named example.com, usa.example.com, and asia.example.com in a single Active Directory forest. A user sits down at a computer that is a member of the usa.example.com Domain and then logs on with an account in the asia.example.com Domain. What happens? The authorization request is referred from one Domain to another until a Domain Controller from the asia.example.com Domain is contacted that can authorize the user.

Note that this situation—a user logging onto a computer using an account in a Domain different from the Domain the computer is a member of—will occur less often in Windows 2000 than in Windows NT 4.0.

In Windows NT 4.0, it was good practice to have the computer in a child Domain (the resource Domain) and the user account in the partner Domain (the account Domain). With Windows 2000, it is only roaming users, using someone else's computer, that will do cross-Domain logon. Users using their own computers, even roaming users using their laptops, will tend to be authenticated by the Domain that their computer is a member of.

The steps for authenticating rebecca@asia.kapoho.com using Kerberos are shown in Figure 4.6.3, and described in the following list.

Figure 4.6.3 Authenticating an account from a trusted Domain.

  1. The user logs on as rebecca@asia.kapoho.com. The client computer sends an authorization request to a Domain Controller in its home Domain, usa.kapoho.com.

  2. The Domain Controller responds with a referral, which consists of a session ticket to a Domain Controller in the parent Domain kapoho.com.

  3. The client sends an authorization request to a Domain Controller in kapoho.com, using the session ticket from the previous step.

  4. The kapoho.com Domain Controller responds with a session ticket to a Domain Controller in asia.kapoho.com.

  5. The client sends an authorization request to a Domain Controller in asia.example.com, using the session ticket it got from the example.com Domain Controller.

  6. If the DC successfully authenticates Rebecca, the asia.kapoho.com Domain Controller queries the Global Catalog to determine Universal Group membership.

  7. The GC will return all Universal groups that Rebecca is a member of.

  8. The asia.example.com Domain Controller returns a session ticket to the client computer for Rebecca, and the logon process can continue.

Thus, there are four Domain Controllers that are involved in authenticating JDoe: the Domain Controllers in usa.example.com, example.com, asia.example.com, and a Global Catalog server. All four Domain Controllers would have to be available on the network in order for Rebecca to log on. If any of these four servers is not available, the logon will fail. In addition, the client would also need to have access to a DNS server capable of resolving the necessary DNS records to allow the client to contact the various Domain Controllers.

Keep Domain Trees Flat

The need for these servers to be available affects the placement of Domain Controllers on your network and your site design. As a practical matter, it's a good idea to keep your Domain trees flat rather than deep because it reduces the number of points of failure for logon throughout the enterprise, as well as reducing the number of referrals. You can also mitigate some of this risk and possibly improve performance through the use of cross-link trusts.

NTLM Authentication

The Windows NT Lan Manager (NTLM) protocol was the default for network authentication in Microsoft Windows NT version 4.0. In NTLM authentication, it is the computer that is receiving the connection request (the server) that has to authenticate the user.

Although Kerberos has replaced NTLM in Windows 2000 as the default, it is still used in these situations:

  • When connecting to a Windows 2000 computer that is not a member of a Domain

  • When connecting to a computer that is running an earlier version of Windows

  • When logging on to a Windows 2000 computer that is a member of a Windows NT 4.0 Domain

Computers that are running Windows networking clients, such as Windows NT 4.0, Windows 95, and Windows 98, are able to log on to a Windows 2000 Domain by using NTLM and can find a Domain Controller using the NetBIOS name of the Domain. To these clients, the Windows 2000 Domain behaves just like a Windows NT 4.0 Domain.

Windows 2000 computers can use NTLM when logging on to a Windows NT 4.0 BDC; however, no Group Policy objects or logon scripts will be processed.

Windows 95 and Windows 98 computers that have the Directory Services client software installed log on to the Domain by using the NTLM authentication protocol. After logging on, these clients will use Kerberos instead of NTLM when connecting to network servers. For example, the client computer will use Kerberos to obtain a session ticket when connecting to a service on a Windows 2000 computer.

Single Domain NTLM Authentication

When a client logs on to a Domain by using the NTLM protocol, the client presents a logon request to a Domain Controller. The Domain Controller authenticates the user and returns a logon response to the client that includes all of the user's SIDs.

Every time the client connects to a new server on the network (that is, a new NetBIOS session is requested), the server has to query a Domain Controller to authenticate the user. If a Domain Controller is unavailable when the client attempts to connect to a server, the user cannot be authenticated and the session will be denied—even if the user was successful logging in to the Domain only moments before.

Multiple Domain NTLM Authentication

If the Active Directory Domains are in Mixed mode, trusts are not transitive for clients using NTLM. A user will only be able to log on using accounts from the computer's Domain or Domains directly trusted by the computer's Domain. For example, a user at a computer in usa.example.com would be unable to log on with an account from asia.example.com unless a cross-link trust was created directly between the two Domains.

If the Active Directory Domains are in Native mode, the user can be authenticated by any Domain in the forest, even if NTLM is used.

Troubleshooting

When troubleshooting problems with logging on or connecting to a network resource, here are the first things to check:

  • Make sure that you have network connectivity. Try pinging a known server on a remote IP subnet.

  • If logging on interactively, check the username and password to ensure that they are entered correctly (passwords are case-sensitive; usernames are not). If necessary, reset the user password in Active Directory.

  • Verify the configuration of TCP/IP, especially the name server addresses (DNS and WINS). Verify that the name servers are online and responding.

  • Verify that all Domain Controllers required for authentication are available. Verify that a Global Catalog server is available.

Table 4.6.1 shows troubleshooting tips dealing with interactive logon.

Table 4.6.1 Troubleshooting Interactive Logon

Symptom

Explanation/Resolution

Bad username or password

If the username or password is typed incorrectly, the message The System could not log you on displays. Make sure your user name and Domain are correct and then type your password again. Letters in the password must be typed using the correct case. Make sure that Caps Lock is not accidentally on.

No Domain Controller found

If the system cannot locate a Domain Controller, the message The system cannot log you on now because the Domain <Domain name> is not available will appear. If the user has not logged on at that computer before, he will not be able to log on. Verify the availability of appropriate records in DNS for the Domain Controllers and Global Catalog server in the Domain name shown.

 

If the user is logged on using cached credentials, he will be unable to change his password until a Domain Controller is available.

 

Verify that the Domain Controllers are configured as WINS clients and that a WINS server is available. Also verify that the computer is a WINS client. Verify the spelling of the Domain name.

 

Check DNS for appropriate SRV records for Domain Controllers. Use Nslookup to verify how DNS responds to queries for Domain Controllers.

 

Check WINS for appropriate entries for Domain Controllers. Use Nbtstat to verify that the Domain Controllers are registering the correct NetBIOS names.

Wrong desktop settings

The desktop configuration at the end of the logon process is the result of the profile, policies, and logon script for the user. Verify the settings in Active Directory for the user account and the contents of the policies for the organizational units that the user belongs to.

No logon prompt appears at startup

The system may be configured to log on automatically.

Policy problem

Use the Group Policy tools from the Resource Kit, including Gpresult.exe, to resolve policy issues.

Other problems

Verify that the NetLogon service is running on the computer. Look at the System Log in Event Viewer for possible error messages.

Some Domains in the forest do not appear in the drop-down list

If the Windows 2000 Domain is in Mixed mode, trust relationships for Windows NT 4.0 clients are not transitive. Only Domains that have the computer's Domain will appear in relationships or change the Domain to Native mode.


See Table 4.6.2 for troubleshooting tips regarding network logon.

Table 4.6.2 Troubleshooting Network Logon

Symptom

Explanation/Resolution

Access denied

The user's account cannot be authenticated, the user has inadequate permissions to the requested share, or the user has inadequate rights on the server. If no trust exists between the user's Domain and the Domain of the server, specify the Domain name and username of an account with adequate access to the server when connecting.

Network path not found

The server is unavailable on the network, there is a network connectivity problem, or the path was entered incorrectly.


Table 4.6.3 shows troubleshooting tips involving service logon.

Table 4.6.3 Troubleshooting Service Logon

Symptom

Explanation/Resolution

Service failed to start

Look for error messages in the System Log in Event Viewer.

For more information, see "Event Viewer" in Chapter 3.3, "Using Administrative Tools."

 

Make sure that the service account has adequate permissions to files or other objects accessed by the service.

 

Make sure that the service account has the Log On as a Service user right and that the username and password are correct.


InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020