Windows 10: Enter Network Credentials Username and Password for a computer that already has «no password required sharing is enabled»

I’ve been fighting with this problem for about a week now off and on, and I haven’t been able to find any workable solution until today. I thought I’d share with the topic of the search I was most using to maybe help other people who run up against it.

• I just built a new PC, (VadersFist) and have my old PC (VoodooChild) set up as a Backup Storage/HTPC.
• VoodooChild had previously been my main PC, and I did not do a fresh install of Windows. My bad.
• I have used my microsoft account on both PCs, even though I had disabled it on VoodooChild when I built VadersFist.
• As soon as I deleted the Microsoft account from VoodooChild I could no longer access files there. I had password protected sharing disabled, as well as every other regular thing to check. (Both were networked, all were visible, both were turned on and off again multiple times)
• My flatmate, who obviously has never shared a microsoft account with me could still view files on VoodooChild with no problems whatsoever.
• When I did try to access the new PC (VoodooChild), I would get a request to «Enter Network Credentials» Asking for my username, my password, and listing my domain as VadersFist (which is my new PC).

• Confirm that Password Enabled Sharing is set to off.
• Turn your computer on and off again.
• When prompted to put in your network credentials. use the microsoft account credentials that is shared between both PCs. REGARDLESS IF THEY ARE ACTIVE.
• Hopefully, profit.

I hope this helps someone in the future so they can avoid the frustration I have faced over the past few days.

Create a local user or administrator account in Windows 10

You can create a local user account (an offline account) for anyone who will frequently use your PC. The best option in most cases, though, is for everyone who uses your PC to have a Microsoft account.

If needed, the local user account can have administrator permissions; however, it’s better to just create a local user account whenever possible.

Caution: A user with an administrator account can access anything on the system, and any malware they encounter can use the administrator permissions to potentially infect or damage any files on the system. Only grant that level of access when absolutely necessary and to people you trust.

As you create an account, remember that choosing a password and keeping it safe are essential steps. Because we don’t know your password, if you forget it or lose it, we can’t recover it for you.

If you’re using Windows 10, version 1803 and later, you can add security questions as you’ll see in step 4 under Create a local user account. With answers to your security questions, you can reset your Windows 10 local account password. Not sure which version you have? You can check your version.

Create a local user account

Select Start > Settings > Accounts and then select Family & other users. (In some versions of Windows you’ll see Other users.)

Select Add someone else to this PC.

Select I don’t have this person’s sign-in information, and on the next page, select Add a user without a Microsoft account.

Enter a user name, password, or password hint—or choose security questions—and then select Next.

Change a local user account to an administrator account

Select Start > Settings > Accounts .

Under Family & other users, select the account owner name (you should see «Local Account» below the name), then select Change account type.

Note: If you choose an account that shows an email address or doesn’t say «Local account», then you’re giving administrator permissions to a Microsoft account, not a local account.

Under Account type, select Administrator, and then select OK.

Sign in with the new administrator account.

Service Accounts

Applies to

• Windows 10
• Windows Server 2016

This topic for the IT professional explains group and standalone managed service accounts, and the computer-specific virtual computer account, and it points to resources about these service accounts.

Overview

A service account is a user account that is created explicitly to provide a security context for services running on Windows Server operating systems. The security context determines the service’s ability to access local and network resources. The Windows operating systems rely on services to run various features. These services can be configured through the applications, the Services snap-in, or Task Manager, or by using Windows PowerShell.

This topic contains information about the following types of service accounts:

Standalone managed service accounts

A managed service account is designed to isolate domain accounts in crucial applications, such as Internet Information Services (IIS), and eliminate the need for an administrator to manually administer the service principal name (SPN) and credentials for the accounts.

To use managed service accounts, the server on which the application or service is installed must be running at least Windows ServerВ 2008В R2. One managed service account can be used for services on a single computer. Managed service accounts cannot be shared between multiple computers, and they cannot be used in server clusters where a service is replicated on multiple cluster nodes. For this scenario, you must use a group managed service account. For more information, see Group Managed Service Accounts Overview.

In addition to the enhanced security that is provided by having individual accounts for critical services, there are four important administrative benefits associated with managed service accounts:

You can create a class of domain accounts that can be used to manage and maintain services on local computers.

Unlike domain accounts in which administrators must reset manually passwords, the network passwords for these accounts are automatically reset.

You do not have to complete complex SPN management tasks to use managed service accounts.

Administrative tasks for managed service accounts can be delegated to non-administrators.

Software requirements

Managed service accounts apply to the Windows operating systems that are designated in the Applies To list at the beginning of this topic.

Group managed service accounts

Group managed service accounts are an extension of the standalone managed service accounts, which were introduced in Windows ServerВ 2008В R2. These are managed domain accounts that provide automatic password management and simplified service principal name (SPN) management, including delegation of management to other administrators.

The group managed service account provides the same functionality as a standalone managed service account within the domain, but it extends that functionality over multiple servers. When connecting to a service that is hosted on a server farm, such as Network Load Balancing, the authentication protocols that support mutual authentication require all instances of the services to use the same principal. When group managed service accounts are used as service principals, the Windows Server operating system manages the password for the account instead of relying on the administrator to manage the password.

The Microsoft Key Distribution Service (kdssvc.dll) provides the mechanism to securely obtain the latest key or a specific key with a key identifier for an Active Directory account. This service was introduced in Windows Server 2012, and it does not run on previous versions of the Windows Server operating system. The Key Distribution Service shares a secret, which is used to create keys for the account. These keys are periodically changed. For a group managed service account, the domain controller computes the password on the key that is provided by the Key Distribution Services, in addition to other attributes of the group managed service account.

Practical applications

Group managed service accounts provide a single identity solution for services running on a server farm, or on systems that use Network Load Balancing. By providing a group managed service account solution, services can be configured for the group managed service account principal, and the password management is handled by the operating system.

By using a group managed service account, services or service administrators do not need to manage password synchronization between service instances. The group managed service account supports hosts that are kept offline for an extended time period and the management of member hosts for all instances of a service. This means that you can deploy a server farm that supports a single identity to which existing client computers can authenticate without knowing the instance of the service to which they are connecting.

Failover clusters do not support group managed service account s. However, services that run on top of the Cluster service can use a group managed service account or a standalone managed service account if they are a Windows service, an App pool, a scheduled task, or if they natively support group managed service account or standalone managed service accounts.

Software requirements

Group managed service accounts can only be configured and administered on computers running at least Windows Server 2012, but they can be deployed as a single service identity solution in domains that still have domain controllers running operating systems earlier than Windows Server 2012. There are no domain or forest functional level requirements.

A 64-bit architecture is required to run the Windows PowerShell commands that are used to administer group managed service accounts.

A managed service account is dependent on encryption types supported by Kerberos. When a client computer authenticates to a server by using Kerberos protocol, the domain controller creates a Kerberos service ticket that is protected with encryption that the domain controller and the server support. The domain controller uses the account’s msDS-SupportedEncryptionTypes attribute to determine what encryption the server supports, and if there is no attribute, it assumes that the client computer does not support stronger encryption types. The Advanced Encryption Standard (AES) should always be explicitly configured for managed service accounts. If computers that host the managed service account are configured to not support RC4, authentication will always fail.

NoteВ В Introduced in WindowsВ ServerВ 2008В R2, the Data Encryption Standard (DES) is disabled by default. For more information about supported encryption types, see Changes in Kerberos Authentication.

Group managed service accounts are not applicable in Windows operating systems prior to Windows Server 2012.

Virtual accounts

Virtual accounts were introduced in Windows ServerВ 2008В R2 and WindowsВ 7, and are managed local accounts that provide the following features to simplify service administration:

The virtual account is automatically managed.

The virtual account can access the network in a domain environment.

No password management is required. For example, if the default value is used for the service accounts during SQL Server setup on Windows ServerВ 2008В R2, a virtual account that uses the instance name as the service name is established in the format NT SERVICE\ .

Services that run as virtual accounts access network resources by using the credentials of the computer account in the format \ $.

For information about how to configure and use virtual service accounts, see Service Accounts Step-by-Step Guide.

Software requirements

Virtual accounts apply to the Windows operating systems that are designated in the Applies To list at the beginning of this topic.

See also

The following table provides links to additional resources that are related to standalone managed service accounts, group managed service accounts, and virtual accounts.

User Account Control Group Policy and registry key settings

Applies to

• Windows 10
• Windows Server 2016

Group Policy settings

There are 10 Group Policy settings that can be configured for User Account Control (UAC). The table lists the default for each of the policy settings, and the following sections explain the different UAC policy settings and provide recommendations. These policy settings are located in Security Settings\Local Policies\Security Options in the Local Security Policy snap-in. For more information about each of the Group Policy settings, see the Group Policy description. For information about the registry key settings, see Registry key settings.

Group Policy setting	Registry key	Default
User Account Control: Admin Approval Mode for the built-in Administrator account	FilterAdministratorToken	Disabled
User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop	EnableUIADesktopToggle	Disabled
User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode	ConsentPromptBehaviorAdmin	Prompt for consent for non-Windows binaries
User Account Control: Behavior of the elevation prompt for standard users	ConsentPromptBehaviorUser	Prompt for credentials on the secure desktop
User Account Control: Detect application installations and prompt for elevation	EnableInstallerDetection	Enabled (default for home) Disabled (default for enterprise)
User Account Control: Only elevate executables that are signed and validated	ValidateAdminCodeSignatures	Disabled
User Account Control: Only elevate UIAccess applications that are installed in secure locations	EnableSecureUIAPaths	Enabled
User Account Control: Run all administrators in Admin Approval Mode	EnableLUA	Enabled
User Account Control: Switch to the secure desktop when prompting for elevation	PromptOnSecureDesktop	Enabled
User Account Control: Virtualize file and registry write failures to per-user locations	EnableVirtualization	Enabled

User Account Control: Admin Approval Mode for the built-in Administrator account

The User Account Control: Admin Approval Mode for the built-in Administrator account policy setting controls the behavior of Admin Approval Mode for the built-in Administrator account.

The options are:

• Enabled. The built-in Administrator account uses Admin Approval Mode. By default, any operation that requires elevation of privilege will prompt the user to approve the operation.
• Disabled. (Default) The built-in Administrator account runs all applications with full administrative privilege.

User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop

The User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop policy setting controls whether User Interface Accessibility (UIAccess or UIA) programs can automatically disable the secure desktop for elevation prompts used by a standard user.

The options are:

• Enabled. UIA programs, including Windows Remote Assistance, automatically disable the secure desktop for elevation prompts. If you do not disable the User Account Control: Switch to the secure desktop when prompting for elevation policy setting, the prompts appear on the interactive user’s desktop instead of the secure desktop.
• Disabled. (Default) The secure desktop can be disabled only by the user of the interactive desktop or by disabling the User Account Control: Switch to the secure desktop when prompting for elevation policy setting.

UIA programs are designed to interact with Windows and application programs on behalf of a user. This policy setting allows UIA programs to bypass the secure desktop to increase usability in certain cases; however, allowing elevation requests to appear on the interactive desktop instead of the secure desktop can increase your security risk.

UIA programs must be digitally signed because they must be able to respond to prompts regarding security issues, such as the UAC elevation prompt. By default, UIA programs are run only from the following protected paths:

• . \Program Files, including subfolders
• . \Program Files (x86), including subfolders for 64-bit versions of Windows
• . \Windows\System32

The User Account Control: Only elevate UIAccess applications that are installed in secure locations policy setting disables the requirement to be run from a protected path.

While this policy setting applies to any UIA program, it is primarily used in certain remote assistance scenarios, including the Windows Remote Assistance program in Windows 7.

If a user requests remote assistance from an administrator and the remote assistance session is established, any elevation prompts appear on the interactive user’s secure desktop and the administrator’s remote session is paused. To avoid pausing the remote administrator’s session during elevation requests, the user may select the Allow IT Expert to respond to User Account Control prompts check box when setting up the remote assistance session. However, selecting this check box requires that the interactive user respond to an elevation prompt on the secure desktop. If the interactive user is a standard user, the user does not have the required credentials to allow elevation.

If you enable this policy setting, requests for elevation are automatically sent to the interactive desktop (not the secure desktop) and also appear on the remote administrator’s view of the desktop during a remote assistance session. This allows the remote administrator to provide the appropriate credentials for elevation.

This policy setting does not change the behavior of the UAC elevation prompt for administrators.

If you plan to enable this policy setting, you should also review the effect of the User Account Control: Behavior of the elevation prompt for standard users policy setting. If it is configured as Automatically deny elevation requests, elevation requests are not presented to the user.

User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode

The User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode policy setting controls the behavior of the elevation prompt for administrators.

The options are:

Elevate without prompting. Allows privileged accounts to perform an operation that requires elevation without requiring consent or credentials.

Note Use this option only in the most constrained environments.

Prompt for credentials on the secure desktop. When an operation requires elevation of privilege, the user is prompted on the secure desktop to enter a privileged user name and password. If the user enters valid credentials, the operation continues with the user’s highest available privilege.

Prompt for consent on the secure desktop. When an operation requires elevation of privilege, the user is prompted on the secure desktop to select either Permit or Deny. If the user selects Permit, the operation continues with the user’s highest available privilege.

Prompt for credentials. When an operation requires elevation of privilege, the user is prompted to enter an administrative user name and password. If the user enters valid credentials, the operation continues with the applicable privilege.

Prompt for consent. When an operation requires elevation of privilege, the user is prompted to select either Permit or Deny. If the user selects Permit, the operation continues with the user’s highest available privilege.

Prompt for consent for non-Windows binaries. (Default) When an operation for a non-Microsoft application requires elevation of privilege, the user is prompted on the secure desktop to select either Permit or Deny. If the user selects Permit, the operation continues with the user’s highest available privilege.

User Account Control: Behavior of the elevation prompt for standard users

The User Account Control: Behavior of the elevation prompt for standard users policy setting controls the behavior of the elevation prompt for standard users.

The options are:

• Automatically deny elevation requests. When an operation requires elevation of privilege, a configurable access denied error message is displayed. An enterprise that is running desktops as standard user may choose this setting to reduce help desk calls.
• Prompt for credentials on the secure desktop. (Default) When an operation requires elevation of privilege, the user is prompted on the secure desktop to enter a different user name and password. If the user enters valid credentials, the operation continues with the applicable privilege.
• Prompt for credentials. When an operation requires elevation of privilege, the user is prompted to enter an administrative user name and password. If the user enters valid credentials, the operation continues with the applicable privilege.

User Account Control: Detect application installations and prompt for elevation

The User Account Control: Detect application installations and prompt for elevation policy setting controls the behavior of application installation detection for the computer.

The options are:

• Enabled. (Default for home) When an application installation package is detected that requires elevation of privilege, the user is prompted to enter an administrative user name and password. If the user enters valid credentials, the operation continues with the applicable privilege.
• Disabled. (Default for enterprise) Application installation packages are not detected and prompted for elevation. Enterprises that are running standard user desktops and use delegated installation technologies such as Group Policy Software Installation or Systems Management Server (SMS) should disable this policy setting. In this case, installer detection is unnecessary.

User Account Control: Only elevate executables that are signed and validated

The User Account Control: Only elevate executables that are signed and validated policy setting enforces public key infrastructure (PKI) signature checks for any interactive applications that request elevation of privilege. Enterprise administrators can control which applications are allowed to run by adding certificates to the Trusted Publishers certificate store on local computers.

The options are:

• Enabled. Enforces the PKI certification path validation for a given executable file before it is permitted to run.
• Disabled. (Default) Does not enforce PKI certification path validation before a given executable file is permitted to run.

User Account Control: Only elevate UIAccess applications that are installed in secure locations

The User Account Control: Only elevate UIAccess applications that are installed in secure locations policy setting controls whether applications that request to run with a User Interface Accessibility (UIAccess) integrity level must reside in a secure location in the file system. Secure locations are limited to the following:

• . \Program Files, including subfolders
• . \Windows\system32
• . \Program Files (x86), including subfolders for 64-bit versions of Windows

Note Windows enforces a PKI signature check on any interactive application that requests to run with a UIAccess integrity level regardless of the state of this security setting.

The options are:

• Enabled. (Default) If an application resides in a secure location in the file system, it runs only with UIAccess integrity.
• Disabled. An application runs with UIAccess integrity even if it does not reside in a secure location in the file system.

User Account Control: Run all administrators in Admin Approval Mode

The User Account Control: Run all administrators Admin Approval Mode policy setting controls the behavior of all UAC policy settings for the computer. If you change this policy setting, you must restart your computer.

The options are:

• Enabled. (Default) Admin Approval Mode is enabled. This policy must be enabled and related UAC policy settings must also be set appropriately to allow the built-in Administrator account and all other users who are members of the Administrators group to run in Admin Approval Mode.
• Disabled. Admin Approval Mode and all related UAC policy settings are disabled.

Note If this policy setting is disabled, the Security Center notifies you that the overall security of the operating system has been reduced.

User Account Control: Switch to the secure desktop when prompting for elevation

The User Account Control: Switch to the secure desktop when prompting for elevation policy setting controls whether the elevation request prompt is displayed on the interactive user’s desktop or the secure desktop.

The options are:

• Enabled. (Default) All elevation requests go to the secure desktop regardless of prompt behavior policy settings for administrators and standard users.
• Disabled. All elevation requests go to the interactive user’s desktop. Prompt behavior policy settings for administrators and standard users are used.

When this policy setting is enabled, it overrides the User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode policy setting. The following table describes the behavior of the elevation prompt for each of the administrator policy settings when the User Account Control: Switch to the secure desktop when prompting for elevation policy setting is enabled or disabled.

Administrator policy setting	Enabled	Disabled
Prompt for credentials on the secure desktop	The prompt appears on the secure desktop.	The prompt appears on the secure desktop.
Prompt for consent on the secure desktop	The prompt appears on the secure desktop.	The prompt appears on the secure desktop.
Prompt for credentials	The prompt appears on the secure desktop.	The prompt appears on the interactive user’s desktop.
Prompt for consent	The prompt appears on the secure desktop.	The prompt appears on the interactive user’s desktop.
Prompt for consent for non-Windows binaries	The prompt appears on the secure desktop.	The prompt appears on the interactive user’s desktop.

When this policy setting is enabled, it overrides the User Account Control: Behavior of the elevation prompt for standard users policy setting. The following table describes the behavior of the elevation prompt for each of the standard user policy settings when the User Account Control: Switch to the secure desktop when prompting for elevation policy setting is enabled or disabled.

Standard policy setting	Enabled	Disabled
Automatically deny elevation requests	No prompt. The request is automatically denied.	No prompt. The request is automatically denied.
Prompt for credentials on the secure desktop	The prompt appears on the secure desktop.	The prompt appears on the secure desktop.
Prompt for credentials	The prompt appears on the secure desktop.	The prompt appears on the interactive user’s desktop.

User Account Control: Virtualize file and registry write failures to per-user locations

The User Account Control: Virtualize file and registry write failures to per-user locations policy setting controls whether application write failures are redirected to defined registry and file system locations. This policy setting mitigates applications that run as administrator and write run-time application data to %ProgramFiles%, %Windir%, %Windir%\system32, or HKLM\Software.

The options are:

• Enabled. (Default) Application write failures are redirected at run time to defined user locations for both the file system and registry.
• Disabled. Applications that write data to protected locations fail.

Registry key settings

The registry keys are found in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System. For information about each of the registry keys, see the associated Group Policy description.