Turn on automatic logon in Windows

This article describes how to configure Windows to automate the logon process by storing your password and other pertinent information in the registry database. By using this feature, other users can start your computer and use the account that you establish to automatically log on.

Original product version: В Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Original KB number: В 324737

The autologon feature is provided as a convenience. However, this feature may be a security risk. If you set a computer for autologon, anyone who can physically obtain access to the computer can gain access to all the computer’s contents, including any networks it is connected to. Additionally, when autologon is turned on, the password is stored in the registry in plain text. The specific registry key that stores this value can be remotely read by the Authenticated Users group. This setting is recommended only for cases in which the computer is physically secured and steps have been taken to make sure that untrusted users cannot remotely access the registry.

Use Registry Editor to turn on automatic logon

This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, see How to back up and restore the registry in Windows.

To use Registry Editor to turn on automatic logon, follow these steps:

Click Start, and then click Run.

In the Open box, type Regedit.exe, and then press Enter.

Locate the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon subkey in the registry.

Double-click the DefaultUserName entry, type your user name, and then click OK.

Double-click the DefaultPassword entry, type your password, and then click OK.

If the DefaultPassword value does not exist, it must be added. To add the value, follow these steps:

On the Edit menu, click New, and then point to String Value.

Type DefaultPassword, and then press Enter.

Double-click DefaultPassword.

In the Edit String dialog, type your password and then click OK.

If no DefaultPassword string is specified, Windows automatically changes the value of the AutoAdminLogon key from 1 (true) to 0 (false), disabling the AutoAdminLogon feature.

On the Edit menu, click New, and then point to String Value.

Type AutoAdminLogon, and then press Enter.

Double-click AutoAdminLogon.

In the Edit String dialog box, type 1 and then click OK.

If you have joined the computer to a domain, you should add the DefaultDomainName value, and the data for the value should be set as the fully qualified domain name (FQDN) of the domain, for example contoso.com. .

Exit Registry Editor.

Click Start, click Shutdown, and then type a reason in the Comment text box.

Click OK to turn off your computer.

Restart your computer. You can now log on automatically.

• To bypass the AutoAdminLogon process and to log on as a different user, press and hold the Shift key after you log off or after Windows restarts.
• This registry change does not work if the Logon Banner value is defined on the server either by a Group Policy object (GPO) or by a local policy. When the policy is changed so that it does not affect the computer, the autologon feature works as expected.
• When Exchange Active Sync (EAS) password restrictions are active, the autologon feature does not work. This behavior is by design. This behavior is caused by a change in Windows 8.1 and does not affect Windows 8 or earlier versions. To work around this behavior in Windows 8.1 and later versions, remove the EAS policies in Control Panel.
• An interactive console logon that has a different user on the server changes the DefaultUserName registry entry as the last logged-on user indicator. AutoAdminLogon relies on the DefaultUserName entry to match the user and password. Therefore, AutoAdminLogon may fail. You can configure a shutdown script to set the correct DefaultUserName.
• You can use the Sysinternals tool AutoLogon to enable this functionality easier. This tool also helps you to use an encrypted version of password.

Windows Logon Scenarios

Applies To: Windows Server (Semi-Annual Channel), Windows Server 2016

This reference topic for the IT professional summarizes common Windows logon and sign-in scenarios.

The Windows operating systems require all users to log on to the computer with a valid account to access local and network resources. Windows-based computers secure resources by implementing the logon process, in which users are authenticated. After a user is authenticated, authorization and access control technologies implement the second phase of protecting resources: determining if the authenticated user is authorized to access a resource.

The contents of this topic apply to versions of Windows designated in the Applies to list at the beginning of this topic.

In addition, applications and services can require users to sign in to access those resources that are offered by the application or service. The sign-in process is similar to the logon process, in that a valid account and correct credentials are required, but logon information is stored in the Security Account Manager (SAM) database on the local computer and in Active Directory where applicable. Sign-in account and credential information is managed by the application or service, and optionally can be stored locally in Credential Locker.

To understand how authentication works, see Windows Authentication Concepts.

This topic describes the following scenarios:

Interactive logon

The logon process begins either when a user enters credentials in the credentials entry dialog box, or when the user inserts a smart card into the smart card reader, or when the user interacts with a biometric device. Users can perform an interactive logon by using a local user account or a domain account to log on to a computer.

The following diagram shows the interactive logon elements and logon process.

Windows Client Authentication Architecture

Local and domain logon

Credentials that the user presents for a domain logon contain all the elements necessary for a local logon, such as account name and password or certificate, and Active Directory domain information. The process confirms the user’s identification to the security database on the user’s local computer or to an Active Directory domain. This mandatory logon process cannot be turned off for users in a domain.

Users can perform an interactive logon to a computer in either of two ways:

Locally, when the user has direct physical access to the computer, or when the computer is part of a network of computers.

A local logon grants a user permission to access Windows resources on the local computer. A local logon requires that the user has a user account in the Security Accounts Manager (SAM) on the local computer. The SAM protects and manages user and group information in the form of security accounts stored in the local computer registry. The computer can have network access, but it is not required. Local user account and group membership information is used to manage access to local resources.

A network logon grants a user permission to access Windows resources on the local computer in addition to any resources on networked computers as defined by the credential’s access token. Both a local logon and a network logon require that the user has a user account in the Security Accounts Manager (SAM) on the local computer. Local user account and group membership information is used to manage access to local resources, and the access token for the user defines what resources can be accessed on networked computers.

A local logon and a network logon are not sufficient to grant the user and computer permission to access and to use domain resources.

Remotely, through Terminal Services or Remote Desktop Services (RDS), in which case the logon is further qualified as remote interactive.

After an interactive logon, Windows runs applications on behalf of the user, and the user can interact with those applications.

A local logon grants a user permission to access resources on the local computer or resources on networked computers. If the computer is joined to a domain, then the Winlogon functionality attempts to log on to that domain.

A domain logon grants a user permission to access local and domain resources. A domain logon requires that the user has a user account in Active Directory. The computer must have an account in the Active Directory domain and be physically connected to the network. Users must also have the user rights to log on to a local computer or a domain. Domain user account information and group membership information are used to manage access to domain and local resources.

Remote logon

In Windows, accessing another computer through remote logon relies on the Remote Desktop Protocol (RDP). Because the user must already have successfully logged on to the client computer before attempting a remote connection, interactive logon processes have successfully finished.

RDP manages the credentials that the user enters by using the Remote Desktop Client. Those credentials are intended for the target computer, and the user must have an account on that target computer. In addition, the target computer must be configured to accept a remote connection. The target computer credentials are sent to attempt to perform the authentication process. If authentication is successful, the user is connected to local and network resources that are accessible by using the supplied credentials.

Network logon

A network logon can only be used after user, service, or computer authentication has taken place. During network logon, the process does not use the credentials entry dialog boxes to collect data. Instead, previously established credentials or another method to collect credentials is used. This process confirms the user’s identity to any network service that the user is attempting to access. This process is typically invisible to the user unless alternate credentials have to be provided.

To provide this type of authentication, the security system includes these authentication mechanisms:

Kerberos version 5 protocol

Public key certificates

Secure Sockets Layer/Transport Layer Security (SSL/TLS)

NTLM, for compatibility with Microsoft Windows NT 4.0-based systems

For information about the elements and processes, see the interactive logon diagram above.

Smart card logon

Smart cards can be used to log on only to domain accounts, not local accounts. Smart card authentication requires the use of the Kerberos authentication protocol. Introduced in Windows 2000 Server, in Windows-based operating systems a public key extension to the Kerberos protocol’s initial authentication request is implemented. In contrast to shared secret key cryptography, public key cryptography is asymmetric, that is, two different keys are needed: one to encrypt, another to decrypt. Together, the keys that are required to perform both operations make up a private/public key pair.

To initiate a typical logon session, a user must prove his or her identity by providing information known only to the user and the underlying Kerberos protocol infrastructure. The secret information is a cryptographic shared key derived from the user’s password. A shared secret key is symmetric, which means that the same key is used for both encryption and decryption.

The following diagram shows the elements and processes required for smart card logon.

Smart Card credential provider architecture

When a smart card is used instead of a password, a private/public key pair stored on the user’s smart card is substituted for the shared secret key, which is derived from the user’s password. The private key is stored only on the smart card. The public key can be made available to anyone with whom the owner wants to exchange confidential information.

For more information about the smart card logon process in Windows, see How smart card sign-in works in Windows.

Biometric logon

A device is used to capture and build a digital characteristic of an artifact, such as a fingerprint. This digital representation is then compared to a sample of the same artifact, and when the two are successfully compared, authentication can occur. Computers running any of the operating systems designated in the Applies to list at the beginning of this topic can be configured to accept this form of logon. However, if biometric logon is only configured for local logon, the user needs to present domain credentials when accessing an Active Directory domain.

Additional resources

For information about how Windows manages credentials submitted during the logon process, see Credentials Management in Windows Authentication.

Unexpectedly slow startup or logon process in Windows Server 2008 R2 or in Windows 7

Symptoms

When you do one of the following on a computer that is running Windows Server 2008 R2 or Windows 7, the operation may take a long time to complete:

Start the computer

Log on to Windows

For example, the computer takes three or more minutes to start.

In the application event log, you may see the following events:

Log Name: Application
Source: Microsoft-Windows-WMI
Event ID: 65
Task Category: None
Level: Warning
Keywords: Classic
Description:
Windows Management Instrumentation (WMI) Service is starting to restore the WMI repository

Log Name: Application
Source: Microsoft-Windows-WMI
Event ID: 43
Task Category: None
Level: Warning
Keywords: Classic
Description:
Windows Management Instrumentation ADAP failed to connect to namespace \\.\root\cimv2 with the following error 0x80080008

Log Name: Application
Source: Microsoft-Windows-WMI
Event ID: 5614
Task Category: None
Level: Information
Keywords: Classic
Description:
During the service startup, the Windows Management Instrumentation service was unable to locate the repository files. A new repository will be created based on the auto-recovery mechanism.

Cause

This issue occurs because the Windows Management Instrumentation (WMI) component unnecessarily performs a full validation of the WMI repository. A full validation of the WMI repository is a time-consuming operation.

Resolution

Hotfix information

A supported hotfix is available from Microsoft. However, this hotfix is intended to correct only the problem that is described in this article. Apply this hotfix only to systems that are experiencing the problem described in this article. This hotfix might receive additional testing. Therefore, if you are not severely affected by this problem, we recommend that you wait for the next software update that contains this hotfix.

If the hotfix is available for download, there is a «Hotfix download available» section at the top of this Knowledge Base article. If this section does not appear, contact Microsoft Customer Service and Support to obtain the hotfix.

Note If additional issues occur or if any troubleshooting is required, you might have to create a separate service request. The usual support costs will apply to additional support questions and issues that do not qualify for this specific hotfix. For a complete list of Microsoft Customer Service and Support telephone numbers or to create a separate service request, visit the following Microsoft Web site:

http://support.microsoft.com/contactus/?ws=supportNote The «Hotfix download available» form displays the languages for which the hotfix is available. If you do not see your language, it is because a hotfix is not available for that language.

Prerequisites

To apply this hotfix, you must be running one of the following operating systems:

Windows 7 Service Pack 1 (SP1)

Windows Server 2008 R2

Windows Server 2008 R2 Service Pack 1 (SP1)

For more information about how to obtain a Windows 7 or Windows Server 2008 R2 service pack, click the following article number to view the article in the Microsoft Knowledge Base:

976932 Information about Service Pack 1 for Windows 7 and for Windows Server 2008 R2

Registry information

To use the hotfix in this package, you do not have to make any changes to the registry.

Restart requirement

You must restart the computer after you apply this hotfix.

Hotfix replacement information

This hotfix does not replace a previously-released hotfix.

File information

The global version of this hotfix installs files that have the attributes that are listed in the following tables. The dates and the times for these files are listed in Coordinated Universal Time (UTC). The dates and the times for these files on your local computer are displayed in your local time together with your current daylight saving time (DST) bias. Additionally, the dates and the times may change when you perform certain operations on the files.

Windows 7 and Windows Server 2008 R2 file information notes

Important Windows 7 hotfixes and Windows Server 2008 R2 hotfixes are included in the same packages. However, hotfixes on the Hotfix Request page are listed under both operating systems. To request the hotfix package that applies to one or both operating systems, select the hotfix that is listed under «Windows 7/Windows Server 2008 R2» on the page. Always refer to the «Applies To» section in articles to determine the actual operating system that each hotfix applies to.

The files that apply to a specific product, milestone (RTM,SP n), and service branch (LDR, GDR) can be identified by examining the file version numbers as shown in the following table.