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 this specific problem. 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:. If you do not see your language, it is because a hotfix is not available for that language.
You must restart your computer to apply the changes after you install this hotfix. However, you do not have to restart the computer immediately after you install this hotfix. The English version of this hotfix has the file attributes or later file attributes that are listed in the following table. The dates and times for these files are listed in coordinated universal time UTC. When you view the file information, it is converted to local time. To work around this problem, configure your wireless access point or device so that it does not send state information during the connection request.
Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section. For additional information about the terminology that is used in this article, click the following article number to view the article in the Microsoft Knowledge Base:. Symptoms When a user tries to connect to your network by using a wireless connection, and when that user's connection request is authenticated and authorized by Microsoft Windows Server Internet Authentication Service IAS , you may experience all the following symptoms: It takes a long time to complete the user's connection.
System services and transport-level applications access an Security Support Provider SSP through the Security Support Provider Interface SSPI in Windows, which provides functions for enumerating the security packages available on a system, selecting a package, and using that package to obtain an authenticated connection.
After the connection has been authenticated, the LSA on the server uses information from the client to build the security context, which contains an access token. The server can then call the SSPI function ImpersonateSecurityContext to attach the access token to an impersonation thread for the service. The integral system manages operating system'specific functions on behalf of the environment system and consists of a security system process the LSA , a workstation service, and a server service.
The security system process deals with security tokens, grants or denies permissions to access user accounts based on resource permissions, handles logon requests and initiates logon authentication, and determines which system resources the operating system needs to audit. SSPI is available through the Secur It provides an abstraction layer between application-level protocols and security protocols. Because different applications require different ways of identifying or authenticating users and different ways of encrypting data as it travels across a network, SSPI provides a way to access dynamic-link libraries DLLs that contain different authentication and cryptographic functions.
Managed service accounts and virtual accounts were introduced in Windows Server R2 and Windows 7 to provide crucial applications, such as Microsoft SQL Server and Internet Information Services IIS , with the isolation of their own domain accounts, while eliminating the need for an administrator to manually administer the service principal name SPN and credentials for these accounts.
Even though most Windows applications run in the security context of the user who starts them, this is not true of services. Many Windows services, such as network and printing services, are started by the service controller when the user starts the computer. These services might run as Local Service or Local System and might continue to run after the last human user logs off. Windows Server R2 introduced services that run under a managed service account, which are domain principals.
Before starting a service, the service controller logs on by using the account that is designated for the service, and then presents the service's credentials for authentication by the LSA. The Windows service implements a programmatic interface that the service controller manager can use to control the service.
A Windows service can be started automatically when the system is started or manually with a service control program. For example, when a Windows client computer joins a domain, the messenger service on the computer connects to a domain controller and opens a secure channel to it. To obtain an authenticated connection, the service must have credentials that the remote computer's Local Security Authority LSA trusts. When communicating with other computers in the network, LSA uses the credentials for the local computer's domain account, as do all other services running in the security context of the Local System and Network Service.
The file Ksecdd. Kernel mode has full access to the hardware and system resources of the computer. The kernel mode stops user-mode services and applications from accessing critical areas of the operating system that they should not have access to.
The Local Security Authority LSA is a protected system process that authenticates and logs users on to the local computer. In addition, LSA maintains information about all aspects of local security on a computer these aspects are collectively known as the local security policy , and it provides various services for translation between names and security identifiers SIDs.
The LSA validates a user's identity based on which of the following two entities issued the user's account:. Local Security Authority. Any workstation or member server can store local user accounts and information about local groups. However, these accounts can be used for accessing only that workstation or computer. Security authority for the local domain or for a trusted domain. The LSA contacts the entity that issued the account and requests verification that the account is valid and that the request originated from the account holder.
The stored credentials let users seamlessly access network resources, such as file shares, Exchange Server mailboxes, and SharePoint sites, without re-entering their credentials for each remote service.
If the account attribute is enabled for a smart card that is required for interactive logon, a random NT hash value is automatically generated for the account instead of the original password hash. The password hash that is automatically generated when the attribute is set does not change. If a user logs on to a Windows-based computer with a password that is compatible with LAN Manager LM hashes, this authenticator is present in memory.
The storage of plaintext credentials in memory cannot be disabled, even if the credential providers that require them are disabled. The stored credentials are directly associated with the Local Security Authority Subsystem Service LSASS logon sessions that have been started after the last restart and have not been closed.
Some of these secrets are credentials that must persist after reboot, and they are stored in encrypted form on the hard disk drive. Credentials stored as LSA secrets might include:. Introduced in Windows 8. This protection increases security for the credentials that the LSA stores and manages. Validation mechanisms rely on the presentation of credentials at the time of logon. However, when the computer is disconnected from a domain controller, and the user is presenting domain credentials, Windows uses the process of cached credentials in the validation mechanism.
Each time a user logs on to a domain, Windows caches the credentials supplied and stores them in the security hive in the registry of the operation system. With cached credentials, the user can log on to a domain member without being connected to a domain controller within that domain. It is not always desirable to use one set of credentials for access to different resources.
For example, an administrator might want to use administrative rather than user credentials when accessing a remote server. Similarly, if a user accesses external resources, such as a bank account, he or she can only use credentials that are different than their domain credentials.
The following sections describe the differences in credential management between current versions of Windows operating systems and the Windows Vista and Windows XP operating systems.
The credentials in plaintext form are sent to the target host where the host attempts to perform the authentication process, and, if successful, connects the user to allowed resources. Introduced in Windows Server R2 and Windows 8. This mode of Remote Desktop causes the client application to perform a network logon challenge-response with the NT one-way function NTOWF or use a Kerberos service ticket when authenticating to the remote host.
After the administrator is authenticated, the administrator does not have the respective account credentials in LSASS because they were not supplied to the remote host. Instead, the administrator has the computer account credentials for the session. Administrator credentials are not supplied to the remote host, so actions are performed as the computer account. Resources are also limited to the computer account, and the administrator cannot access resources with his own account.
When a user signs in on a Windows 8. When Windows Update initiates an automatic restart without user presence, these credentials are used to configure Autologon for the user.
On restart, the user is automatically signed in via the Autologon mechanism, and then the computer is additionally locked to protect the user's session. The locking is initiated through Winlogon whereas the credential management is done by LSA. By automatically signing in and locking the user's session on the console, the user's lock screen applications is restarted and available. The credentials - part of the user's profile - are stored until needed.
This action can increase security on a per-resource basis by ensuring that if one password is compromised, it does not compromise all security. After a user logs on and attempts to access additional password-protected resources, such as a share on a server, and if the user's default logon credentials are not sufficient to gain access, Stored User Names and Passwords is queried.
If alternate credentials with the correct logon information have been saved in Stored User Names and Passwords , these credentials are used to gain access. Otherwise, the user is prompted to supply new credentials, which can then be saved for reuse, either later in the logon session or during a subsequent session.
If Stored User Names and Passwords contains invalid or incorrect credentials for a specific resource, access to the resource is denied, and the Stored User Names and Passwords dialog box does not appear. Some versions of Internet Explorer maintain their own cache for basic authentication. As a result, these credentials can roam with the user if the user's network policy supports Roaming User Profiles.
False enables multiple authentications for the same connections. Note: A setting of true means that the client will be authenticated only once on the same connection.
The default is false. Setting this flag to true specifies that authentication persists only for a single request on a connection.
IIS resets the authentication at the end of each request, and forces reauthentication on the next request of the session. The default value is false. Required Boolean attribute. Specifies whether Windows authentication is enabled. Specifies whether Windows authentication is done in kernel mode.
True specifies that Windows authentication uses kernel mode. Kernel-mode authentication may improve authentication performance and prevent authentication problems with application pools that are configured to use a custom identity. As a best practice, do not disable this setting if you use Kerberos authentication and have a custom identity on the application pool.
The default is true. Optional element. Specifies extended protection options for Windows authentication.
0コメント